Re: [PATCH] pci_dma_rw: return correct value instead of 0

On Thu, Jul 30, 2020 at 12:17:32AM +0200, Emanuele Giuseppe Esposito wrote: > pci_dma_rw currently always returns 0, regardless > of the result of dma_memory_rw. Adjusted to return > the correct value. > > Signed-off-by: Emanuele Giuseppe Esposito > --- > include/hw/pci/pci.h | 3 +-- > 1 file

Re: [PATCH v2 2/3] trace: Add support for recorder back-end

Christophe de Dinechin writes: > On 2020-07-29 at 13:53 CEST, Markus Armbruster wrote... >> Christophe de Dinechin writes: >> >>> On 2020-07-27 at 10:23 CEST, Markus Armbruster wrote... Christophe de Dinechin writes: > On 2020-07-23 at 16:06 CEST, Markus Armbruster wrote...

Re: [PATCH] virtio-mem: Work around format specifier mismatch for RISC-V

On 30.07.20 09:58, Stefano Garzarella wrote: > On Thu, Jul 30, 2020 at 09:51:19AM +0200, David Hildenbrand wrote: >> On 30.07.20 09:49, Stefano Garzarella wrote: >>> On Wed, Jul 29, 2020 at 06:54:38PM -0600, Bruce Rogers wrote: This likely affects other, less popular host architectures as

Re: [PATCH] virtio-mem: Work around format specifier mismatch for RISC-V

On 30.07.20 09:49, Stefano Garzarella wrote: > On Wed, Jul 29, 2020 at 06:54:38PM -0600, Bruce Rogers wrote: >> This likely affects other, less popular host architectures as well. >> Less common host architectures under linux get QEMU_VMALLOC_ALIGN (from >> which VIRTIO_MEM_MIN_BLOCK_SIZE is

Re:Re: What this mean "dead: 1" and "dead: 0 1" on each tb block start?

So, flag is also the paramter index right? ,what about the sync ? At 2020-07-30 00:16:25, "Richard Henderson" wrote: >On 7/29/20 7:27 AM, tugouxp wrote: >> HI folks: >> on each tb block start, there are following ir code, and the most confusing >> me is that the postfix of

Re: [RFC v2 01/76] target/riscv: drop vector 0.7.1 support

On Tue, Jul 28, 2020 at 4:05 AM Alistair Francis wrote: > On Mon, Jul 27, 2020 at 12:54 PM Palmer Dabbelt > wrote: > > > > On Wed, 22 Jul 2020 02:15:24 PDT (-0700), frank.ch...@sifive.com wrote: > > > From: Frank Chang > > > > > > Signed-off-by: Frank Chang > > > --- > > > target/riscv/cpu.c

Re: [PATCH] virtio-mem: Work around format specifier mismatch for RISC-V

On Wed, Jul 29, 2020 at 06:54:38PM -0600, Bruce Rogers wrote: > This likely affects other, less popular host architectures as well. > Less common host architectures under linux get QEMU_VMALLOC_ALIGN (from > which VIRTIO_MEM_MIN_BLOCK_SIZE is derived) define to a variable of > type uintptr, which

Re: [PATCH] virtio-mem: Work around format specifier mismatch for RISC-V

On Thu, Jul 30, 2020 at 09:51:19AM +0200, David Hildenbrand wrote: > On 30.07.20 09:49, Stefano Garzarella wrote: > > On Wed, Jul 29, 2020 at 06:54:38PM -0600, Bruce Rogers wrote: > >> This likely affects other, less popular host architectures as well. > >> Less common host architectures under

[PATCH] qapi: Delete unwanted indentation of top-level expressions

Signed-off-by: Markus Armbruster --- qapi/block-core.json | 24 qapi/ui.json | 4 ++-- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/qapi/block-core.json b/qapi/block-core.json index ab7bf3c612..bdcc8e5f9f 100644 --- a/qapi/block-core.json +++

Re: [PATCH] schemas: Add vim modeline

On Thu, Jul 30, 2020 at 11:07:26AM +0200, Markus Armbruster wrote: > Andrea Bolognani writes: > > > The various schemas included in QEMU use a JSON-based format which > > is, however, strictly speaking not valid JSON. > > > > As a consequence, when vim tries to apply syntax highlight rules > >

Re: [PATCH v2 16/16] hw/block/nvme: remove explicit qsg/iov parameters

On 20-07-30 00:06:38, Klaus Jensen wrote: > From: Klaus Jensen > > Since nvme_map_prp always operate on the request-scoped qsg/iovs, just > pass a single pointer to the NvmeRequest instead of two for each of the > qsg and iov. > > Suggested-by: Minwoo Im > Signed-off-by: Klaus Jensen > --- >

Re: [PATCH v2 14/16] hw/block/nvme: consolidate qsg/iov clearing

On 20-07-30 00:06:36, Klaus Jensen wrote: > From: Klaus Jensen > > Always destroy the request qsg/iov at the end of request use. > > Signed-off-by: Klaus Jensen > --- > hw/block/nvme.c | 52 - > 1 file changed, 21 insertions(+), 31 deletions(-)

Re: [PATCH v2 07/16] hw/block/nvme: add tracing to nvme_map_prp

On Thu, 2020-07-30 at 00:06 +0200, Klaus Jensen wrote: > From: Klaus Jensen > > Add tracing to nvme_map_prp. > > Signed-off-by: Klaus Jensen > --- > hw/block/nvme.c | 2 ++ > hw/block/trace-events | 1 + > 2 files changed, 3 insertions(+) > > diff --git a/hw/block/nvme.c

Re: [PATCH] target/arm: Fix AddPAC error indication

On Tue, 28 Jul 2020 at 20:57, Richard Henderson wrote: > > The definition of top_bit used in this function is one higher > than that used in the Arm ARM psuedo-code, which put the error > indication at top_bit - 1 at the wrong place, which meant that > it wasn't visible to Auth. > > Fixing the

Re: sysbus_create_simple Vs qdev_create

On 30/07/20 12:03, Markus Armbruster wrote: > qdev C layer: > > frob->prop = 42; > > Least cognitive load. > > QOM has no C layer. Not really, a QOM object is totally free to do frob->prop = 42. And just like we didn't do that outside device implementation in qdev as our tithe to the

Re: [PATCH v2 14/16] hw/block/nvme: consolidate qsg/iov clearing

On Jul 30 19:31, Minwoo Im wrote: > On 20-07-30 00:06:36, Klaus Jensen wrote: > > From: Klaus Jensen > > > > Always destroy the request qsg/iov at the end of request use. > > > > Signed-off-by: Klaus Jensen > > --- > > hw/block/nvme.c | 52 - > >

Re: [PATCH 2/2] target/arm: Fix compile error.

On Thu, 30 Jul 2020 at 12:19, Kaige Li wrote: > > On 07/30/2020 04:44 PM, Peter Maydell wrote: > > > On Thu, 30 Jul 2020 at 02:56, Kaige Li wrote: > >> When I compile qemu with such as: > >> > >> git clone https://git.qemu.org/git/qemu.git > >> cd qemu > >> git submodule init > >> git submodule

Re: [PATCH 2/2] target/arm: Fix compile error.

On Thu, 30 Jul 2020 at 12:28, Kaige Li wrote: > > On 07/30/2020 07:21 PM, Peter Maydell wrote: > > Clang, gcc, OSX clang, something else, and which version number? > Sorry for that. Gcc version is 4.9.4. Ah, that makes sense. That's a pretty old version of gcc (it's almost the oldest we still

Re: [PATCH] schemas: Add vim modeline

Daniel P. Berrangé writes: > On Thu, Jul 30, 2020 at 11:07:26AM +0200, Markus Armbruster wrote: >> Andrea Bolognani writes: >> >> > The various schemas included in QEMU use a JSON-based format which >> > is, however, strictly speaking not valid JSON. >> > >> > As a consequence, when vim tries

[PATCH 1/2] qcow2: Release read-only bitmaps when inactivated

During migration, we release all bitmaps after storing them on disk, as long as they are (1) stored on disk, (2) not read-only, and (3) consistent. (2) seems arbitrary, though. The reason we do not release them is because we do not write them, as there is no need to; and then we just forget

Re: [RFC v2 01/76] target/riscv: drop vector 0.7.1 support

On 7/30/20 1:07 AM, Frank Chang wrote: > So, if it's okay, we can skip RVV v0.9 and bump to RVV v1.0 directly in our > next version of patchset. > Which I think may relieve the burden for the community to maintain > multi-version of vector drafts. That would be my preference. Thanks, r~

Re: [PATCH v2 14/16] hw/block/nvme: consolidate qsg/iov clearing

> Hi Minwoo, > > The is that on 'exit' we release request resources (like the qsg and > iov). On 'clear' we initialize the request by clearing the struct. I > guess I could call it nvme_req_init instead maybe, but really - it is > clearing it. Yeah, I just wanted to make it clear to understand

Re: [PATCH v3 08/18] hw/block/nvme: add support for the asynchronous event request command

On Wed, 2020-07-29 at 22:08 +0200, Klaus Jensen wrote: > On Jul 29 21:45, Maxim Levitsky wrote: > > On Wed, 2020-07-29 at 15:37 +0200, Klaus Jensen wrote: > > > On Jul 29 13:43, Maxim Levitsky wrote: > > > > On Mon, 2020-07-06 at 08:12 +0200, Klaus Jensen wrote: > > > > > +

Re: [PATCH] schemas: Add vim modeline

Andrea Bolognani writes: > The various schemas included in QEMU use a JSON-based format which > is, however, strictly speaking not valid JSON. > > As a consequence, when vim tries to apply syntax highlight rules > for JSON (as guessed from the file name), the result is an unreadable > mess which

[PATCH 2/3] softfloat: add APIs to handle alternative sNaN propagation

For "fmax/fmin ft0, ft1, ft2" and if one of the inputs is sNaN, The original logic return NaN and set invalid flag if ft1 == sNaN || ft2 == sNan The alternative path set invalid flag if ft1 == sNaN || ft2 == sNaN return NaN if ft1 == sNaN && ft2 == sNaN The ieee754 spec allows

[PATCH 1/3] softfloat: target/riscv: implement full set fp16 comparision

From: Kito Cheng Implement them in softfloat and remove local version in riscv Signed-off-by: Kito Cheng Signed-off-by: Chih-Min Chao Acked-by: Alex Bennée --- include/fpu/softfloat.h | 41 + target/riscv/vector_helper.c | 25

[PATCH 0/3] float16 APIs and alternative sNaN handling

These patches are separated from riscv vector extension 0.9 patchset. The set includes 1. alternative NaN handlding 2. float16 comparision APIs. 3. float16 to int8/uint8 conversion APIs Chih-Min Chao (1): softfloat: add APIs to handle alternative sNaN propagation Frank Chang (1):

Re: sysbus_create_simple Vs qdev_create

Paolo Bonzini writes: > On 29/07/20 15:18, Markus Armbruster wrote: >>> Even code riddled by backwards-compatibility special cases, such as >>> -accel and -machine, can share code between themselves and -object to >>> some extent; this is thanks to functions such as object_property_parse, >>>

Re: [PATCH v2 07/16] hw/block/nvme: add tracing to nvme_map_prp

On Thu, Jul 30, 2020 at 7:06 AM Klaus Jensen wrote: > > From: Klaus Jensen > > Add tracing to nvme_map_prp. > > Signed-off-by: Klaus Jensen > --- > hw/block/nvme.c | 2 ++ > hw/block/trace-events | 1 + > 2 files changed, 3 insertions(+) > > diff --git a/hw/block/nvme.c b/hw/block/nvme.c

Re: [PATCH] pci_dma_rw: return correct value instead of 0

On Thu, Jul 30, 2020 at 09:58:21AM +0100, Peter Maydell wrote: > On Thu, 30 Jul 2020 at 08:42, Stefano Garzarella wrote: > > I agree that it is better to return the dma_memory_rw() return value, but > > at first look, no one seems to check the return value of pci_dma_rw(), > > pci_dma_read(),

Re: [PATCH-for-5.2 v4] hw/core/qdev: Increase qdev_realize() kindness

Paolo Bonzini writes: > On 29/07/20 09:39, Markus Armbruster wrote: >> Taking a step back, I disagree with the notion that assertions should be >> avoided just because we have an Error **. A programming error doesn't >> become less wrong, and continuing when the program is in disorder >>

Re: [PATCH] pci_dma_rw: return correct value instead of 0

On 30/07/2020 09:41, Stefano Garzarella wrote: On Thu, Jul 30, 2020 at 12:17:32AM +0200, Emanuele Giuseppe Esposito wrote: pci_dma_rw currently always returns 0, regardless of the result of dma_memory_rw. Adjusted to return the correct value. Signed-off-by: Emanuele Giuseppe Esposito ---

Re: [PATCH v2 01/16] hw/block/nvme: memset preallocated requests structures

On Thu, Jul 30, 2020 at 7:06 AM Klaus Jensen wrote: > > From: Klaus Jensen > > This is preparatory to subsequent patches that change how QSGs/IOVs are > handled. It is important that the qsg and iov members of the NvmeRequest > are initially zeroed. > > Signed-off-by: Klaus Jensen >

Re: [PATCH v2 2/3] trace: Add support for recorder back-end

On 2020-07-30 at 10:13 CEST, Markus Armbruster wrote... > Christophe de Dinechin writes: > >> On 2020-07-29 at 13:53 CEST, Markus Armbruster wrote... >>> Christophe de Dinechin writes: >>> On 2020-07-27 at 10:23 CEST, Markus Armbruster wrote... > Christophe de Dinechin writes: >

Re: [PATCH v2 15/16] hw/block/nvme: use preallocated qsg/iov in nvme_dma_prp

On 20-07-30 00:06:37, Klaus Jensen wrote: > From: Klaus Jensen > > Since clean up of the request qsg/iov is now always done post-use, there > is no need to use a stack-allocated qsg/iov in nvme_dma_prp. > > Signed-off-by: Klaus Jensen > Acked-by: Keith Busch > Reviewed-by: Maxim Levitsky

Re: [PATCH 1/1] s390x/s390-virtio-ccw: fix off-by-one in loadparm getter

On Wed, 29 Jul 2020 15:02:22 +0200 Halil Pasic wrote: > As pointed out by Peter, g_memdup(ms->loadparm, sizeof(ms->loadparm) + 1) > reads one past of the end of ms->loadparm, so g_memdup() can not be used > here. > > Let's use malloc and memcpy instead! Hm, an alternative would be to use

Re: [PATCH v2 14/16] hw/block/nvme: consolidate qsg/iov clearing

On Thu, 2020-07-30 at 19:31 +0900, Minwoo Im wrote: > On 20-07-30 00:06:36, Klaus Jensen wrote: > > From: Klaus Jensen > > > > Always destroy the request qsg/iov at the end of request use. > > > > Signed-off-by: Klaus Jensen > > --- > > hw/block/nvme.c | 52

[Bug 1886343] Re: configure has non-posix bash syntax

Fixed in commit b418d2656112174c; this will be in QEMU 5.1. ** Changed in: qemu Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1886343 Title: configure

Re: [PATCH-for-5.2] default-configs: Remove ACPI_CPU_HOTPLUG from MIPS machines

On Fri, 24 Jul 2020 18:52:59 +0200 Philippe Mathieu-Daudé wrote: > No MIPS machine uses the ACPI cpu-hotplug feature > (QEMU implementation is X86 specific). if I recall correctly we were building it to satisfy symbol dependencies due to hw/acpi/piix4.c being shared between x86 and mips. It no

Re: [PATCH 1/1] pci/pcie: refuse another hotplug/unplug event if attention button is pending

On Wed, 29 Jul 2020 08:09:37 +0300 Maxim Levitsky wrote: > On Wed, 2020-07-22 at 19:19 +0300, Maxim Levitsky wrote: > > On Wed, 2020-07-22 at 19:17 +0300, Maxim Levitsky wrote: > > > Curently it is possible to hotplug a device and then immediatly > > > hotunplug it before the OS notices, and

Re: [PATCH 2/2] target/arm: Fix compile error.

On Thu, 30 Jul 2020 at 02:56, Kaige Li wrote: > > When I compile qemu with such as: > > git clone https://git.qemu.org/git/qemu.git > cd qemu > git submodule init > git submodule update --recursive > ./configure > make > > There is error log: > > /home/LiKaige/qemu/target/arm/translate-a64.c: In

Re: [PATCH] pci_dma_rw: return correct value instead of 0

On Thu, 30 Jul 2020 at 08:42, Stefano Garzarella wrote: > I agree that it is better to return the dma_memory_rw() return value, but > at first look, no one seems to check the return value of pci_dma_rw(), > pci_dma_read(), andpci_dma_write(). > > Should we make them void? In general code (eg

Re: [PATCH for-5.1] qapi/machine.json: Fix missing newline in doc comment

Peter Maydell writes: > In commit 176d2cda0dee9f4 we added the @die-id field > to the CpuInstanceProperties struct, but in the process > accidentally removed the newline between the doc-comment > lines for @core-id and @thread-id. > > Put the newline back in; this fixes a misformatting in the >

Re: [PATCH v8 4/7] 9pfs: add new function v9fs_co_readdir_many()

On Mittwoch, 29. Juli 2020 10:12:33 CEST Christian Schoenebeck wrote: > The newly added function v9fs_co_readdir_many() retrieves multiple > directory entries with a single fs driver request. It is intended to > replace uses of v9fs_co_readdir(), the latter only retrives a single > directory entry

Re: [PATCH v2 08/16] hw/block/nvme: add request mapping helper

On Thu, Jul 30, 2020 at 7:06 AM Klaus Jensen wrote: > > From: Klaus Jensen > > Introduce the nvme_map helper to remove some noise in the main nvme_rw > function. > > Signed-off-by: Klaus Jensen > Reviewed-by: Maxim Levitsky > --- > hw/block/nvme.c | 13 ++--- > 1 file changed, 10

Re: [PATCH v2 04/16] hw/block/nvme: remove redundant has_sg member

On Thu, 2020-07-30 at 00:06 +0200, Klaus Jensen wrote: > From: Klaus Jensen > > Remove the has_sg member from NvmeRequest since it's redundant. > > Signed-off-by: Klaus Jensen Reviewed-by: Maxim Levitsky Best regards, Maxim Levitsky > --- > hw/block/nvme.c | 7 ++- >

Re: [PATCH v2 05/16] hw/block/nvme: destroy request iov before reuse

On Thu, 2020-07-30 at 00:06 +0200, Klaus Jensen wrote: > From: Klaus Jensen > > Make sure the request iov is destroyed before reuse; fixing a memory > leak. > > Signed-off-by: Klaus Jensen > --- > hw/block/nvme.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/hw/block/nvme.c

Re: [PATCH v3 0/8] Generalize start-powered-off property from ARM

Le jeu. 30 juil. 2020 03:00, David Gibson a écrit : > On Tue, Jul 28, 2020 at 09:56:36PM -0300, Thiago Jung Bauermann wrote: > > > > Thiago Jung Bauermann writes: > > > > > The ARM code has a start-powered-off property in ARMCPU, which is a > > > subclass of CPUState. This property causes

Re: [PATCH 1/1] s390x/s390-virtio-ccw: fix off-by-one in loadparm getter

On Thu, 30 Jul 2020 11:25:06 +0100 Daniel P. Berrangé wrote: > > /* make a NUL-terminated string */ > > -loadparm_str = g_memdup(ms->loadparm, sizeof(ms->loadparm) + 1); > > -loadparm_str[sizeof(ms->loadparm)] = 0; > > +loadparm_str = g_malloc0(sizeof(ms->loadparm) + 1); > > +

Re: [PATCH v2 1/3] hw/i386: Initialize topo_ids from CpuInstanceProperties

On Wed, 29 Jul 2020 16:22:32 -0500 Babu Moger wrote: > Igor, > Sorry. Few more questions. > > > -Original Message- > > From: Igor Mammedov > > Sent: Wednesday, July 29, 2020 9:12 AM > > To: Moger, Babu > > Cc: pbonz...@redhat.com; r...@twiddle.net; qemu-devel@nongnu.org; > >

Re: [PATCH 2/5] virtiofsd: create lock/pid file in per user cache dir

On Wed, Jul 29, 2020 at 06:14:07PM -0400, Vivek Goyal wrote: > Right now we create lock/pid file in /usr/local/var/... and unprivliged > user does not have access to create files there. > > So create this file in per user cache dir as queried as specified > by environment variable

Re: [RFC PATCH v3 8/8] target/s390x: Use start-powered-off CPUState property

On Tue, 28 Jul 2020 21:51:33 -0300 Thiago Jung Bauermann wrote: > Hi, > > Cornelia Huck writes: > > > On Wed, 22 Jul 2020 23:56:57 -0300 > > Thiago Jung Bauermann wrote: > > > >> Instead of setting CPUState::halted to 1 in s390_cpu_initfn(), use the > >> start-powered-off property which

[PATCH 3/3] softfloat: add fp16 and uint8/int8 interconvert functions

From: Frank Chang Signed-off-by: Frank Chang Reviewed-by: Alex Bennée --- fpu/softfloat.c | 34 ++ include/fpu/softfloat.h | 8 2 files changed, 42 insertions(+) diff --git a/fpu/softfloat.c b/fpu/softfloat.c index 4466ece..c700a39 100644 ---

Re: [PATCH v2 05/16] hw/block/nvme: destroy request iov before reuse

On Thu, Jul 30, 2020 at 7:06 AM Klaus Jensen wrote: > > From: Klaus Jensen > > Make sure the request iov is destroyed before reuse; fixing a memory > leak. > > Signed-off-by: Klaus Jensen Looks good to me and Thanks for splitting this up. Reviewed-by: Minwoo Im

Re: [PATCH v2 04/16] hw/block/nvme: remove redundant has_sg member

On Thu, Jul 30, 2020 at 7:06 AM Klaus Jensen wrote: > > From: Klaus Jensen > > Remove the has_sg member from NvmeRequest since it's redundant. > > Signed-off-by: Klaus Jensen Looks better than the previous one to me. Reviewed-by: Minwoo Im

Re: [PATCH 1/1] s390x/s390-virtio-ccw: fix off-by-one in loadparm getter

On Wed, Jul 29, 2020 at 03:02:22PM +0200, Halil Pasic wrote: > As pointed out by Peter, g_memdup(ms->loadparm, sizeof(ms->loadparm) + 1) > reads one past of the end of ms->loadparm, so g_memdup() can not be used > here. > > Let's use malloc and memcpy instead! > > Fixes: d664548328

Re: [PATCH 2/2] target/arm: Fix compile error.

On 07/30/2020 04:44 PM, Peter Maydell wrote: On Thu, 30 Jul 2020 at 02:56, Kaige Li wrote: When I compile qemu with such as: git clone https://git.qemu.org/git/qemu.git cd qemu git submodule init git submodule update --recursive ./configure make There is error log:

[Bug 1879587] Re: Register number in ESR is incorrect for certain banked registers when switching from AA32 to AA64

** Tags added: arm -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1879587 Title: Register number in ESR is incorrect for certain banked registers when switching from AA32 to AA64 Status in QEMU:

[Bug 1884728] Re: facing build error for qemu-4.0.0 on SUSE11 OS

** Changed in: qemu Status: New => Incomplete ** Changed in: qemu Status: Incomplete => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1884728 Title: facing build error for

Re: [PATCH v4 1/2] nvme: indicate CMB support through controller capabilities register

On Tue, 2020-07-07 at 21:15 +0200, Klaus Jensen wrote: > On Jul 7 19:27, Maxim Levitsky wrote: > > On Wed, 2020-07-01 at 14:48 -0700, Andrzej Jakowski wrote: > > > This patch sets CMBS bit in controller capabilities register when user > > > configures NVMe driver with CMB support, so capabilites

[Bug 1881552] Re: potential AArch64 ABI bug wrt handling of 128-bit bit-fields

The warnings aren't a problem for QEMU because we don't expose these functions as public ABI, so the whole compile will be consistently built with the same compiler version. So we added -Wno-psabi in commit bac8d222a19f4a30d to silence the compiler here. ** Changed in: qemu Status: New =>

[PATCH v2 2/2] target/arm: Fix compile error.

When I compile qemu with such as: git clone https://git.qemu.org/git/qemu.git cd qemu git submodule init git submodule update --recursive ./configure make There is error log: /home/LiKaige/qemu/target/arm/translate-a64.c: In function ‘disas_ldst’:

[PATCH v2 1/2] virtio-mem: Change PRIx32 to PRIXPTR to fix compile error.

When I compile qemu with such as: git clone https://git.qemu.org/git/qemu.git cd qemu git submodule init git submodule update --recursive ./configure make There is error log: /home/LiKaige/qemu/hw/virtio/virtio-mem.c: In function ‘virtio_mem_set_block_size’:

Re: [PATCH] pci_dma_rw: return correct value instead of 0

On Wed, 29 Jul 2020 at 23:19, Emanuele Giuseppe Esposito wrote: > > pci_dma_rw currently always returns 0, regardless > of the result of dma_memory_rw. Adjusted to return > the correct value. > > Signed-off-by: Emanuele Giuseppe Esposito We also have the equivalent patch from Klaus Jensen back

Re: [PATCH] pci_dma_rw: return correct value instead of 0

On Thu, Jul 30, 2020 at 10:50:43AM +0200, Emanuele Giuseppe Esposito wrote: > > > On 30/07/2020 09:41, Stefano Garzarella wrote: > > On Thu, Jul 30, 2020 at 12:17:32AM +0200, Emanuele Giuseppe Esposito wrote: > > > pci_dma_rw currently always returns 0, regardless > > > of the result of

Re: [PATCH v2 16/16] hw/block/nvme: remove explicit qsg/iov parameters

On Thu, 2020-07-30 at 00:06 +0200, Klaus Jensen wrote: > From: Klaus Jensen > > Since nvme_map_prp always operate on the request-scoped qsg/iovs, just > pass a single pointer to the NvmeRequest instead of two for each of the > qsg and iov. > > Suggested-by: Minwoo Im > Signed-off-by: Klaus

Re: [PATCH 1/1] s390x/s390-virtio-ccw: fix off-by-one in loadparm getter

On Thu, 30 Jul 2020 12:26:56 +0200 Cornelia Huck wrote: > On Wed, 29 Jul 2020 15:02:22 +0200 > Halil Pasic wrote: > > > As pointed out by Peter, g_memdup(ms->loadparm, sizeof(ms->loadparm) + 1) > > reads one past of the end of ms->loadparm, so g_memdup() can not be used > > here. > > > >

Re: [PATCH 2/2] target/arm: Fix compile error.

On 07/30/2020 07:21 PM, Peter Maydell wrote: On Thu, 30 Jul 2020 at 12:19, Kaige Li wrote: On 07/30/2020 04:44 PM, Peter Maydell wrote: On Thu, 30 Jul 2020 at 02:56, Kaige Li wrote: When I compile qemu with such as: git clone https://git.qemu.org/git/qemu.git cd qemu git submodule init

Re: [PATCH 1/1] s390x/s390-virtio-ccw: fix off-by-one in loadparm getter

On Thu, 30 Jul 2020 13:25:21 +0200 Halil Pasic wrote: > On Thu, 30 Jul 2020 12:26:56 +0200 > Cornelia Huck wrote: > > > On Wed, 29 Jul 2020 15:02:22 +0200 > > Halil Pasic wrote: > > > > > As pointed out by Peter, g_memdup(ms->loadparm, sizeof(ms->loadparm) + 1) > > > reads one past of the

[PATCH 0/2] qcow2: Release read-only bitmaps when inactivated

Hi, When beginning migration, the qcow2 driver syncs all persistent bitmaps to disk and then releases them. If the user decides to continue on the source after migration, those bitmaps are re-loaded from the qcow2 image. However, we only do this for bitmaps that were actively synced, i.e. R/W

Re: [PATCH v2 1/2] virtio-mem: Change PRIx32 to PRIXPTR to fix compile error.

On 30.07.20 13:57, Kaige Li wrote: > When I compile qemu with such as: > > git clone https://git.qemu.org/git/qemu.git > cd qemu > git submodule init > git submodule update --recursive > ./configure > make > > There is error log: > > /home/LiKaige/qemu/hw/virtio/virtio-mem.c: In function >

[PATCH 2/2] iotests/169: Test source cont with backing bmap

Test migrating from a VM with a persistent bitmap in the backing chain, and then continuing that VM after the migration Signed-off-by: Max Reitz --- tests/qemu-iotests/169 | 64 +- tests/qemu-iotests/169.out | 4 +-- 2 files changed, 65 insertions(+), 3

Re: [PATCH] trace/simple: Allow enabling simple traces from command line

Well, this is a bit embarrassing.  The patch below simply re-introduced the bug which the Fixes: line was trying to fix in the first place. I.e, : - with my patch (just committed as 1b7157be3a8c4300fc8044d40f4b2e64a152a1b4) applied, a QEMU built with simple tracing will always produce a

Re: [PATCH-for-5.1? v2 2/2] util/pagesize: Make qemu_real_host_page_size of type size_t

On Thu, Jul 30, 2020 at 04:12:45PM +0200, Philippe Mathieu-Daudé wrote: > We use different types to hold 'qemu_real_host_page_size'. > Unify picking 'size_t' which seems the best candidate. > > Doing so fix a format string issue in hw/virtio/virtio-mem.c > reported when building with GCC 4.9.4: >

Re: [PATCH-for-5.1? v2 1/2] qemu/osdep: Make QEMU_VMALLOC_ALIGN unsigned long

On Thu, Jul 30, 2020 at 04:12:44PM +0200, Philippe Mathieu-Daudé wrote: > QEMU_VMALLOC_ALIGN is sometimes expanded to signed type, > other times to unsigned. Unify using unsigned. > > Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: David Gibson > --- > include/qemu/osdep.h | 4 ++-- > 1

[RFC PATCH v2 1/2] hw/riscv: sifive_u: Add file-backed OTP.

Add a file-backed implementation for OTP of sifive_u machine. The machine property for file-backed is disabled in default. Do file open, mmap and close for every OTP read/write in case keep the update-to-date snapshot of OTP. Signed-off-by: Green Wan --- hw/riscv/sifive_u.c | 26

Re: [PATCH 1/2] i386/acpi: fix inconsistent QEMU/OVMF device paths

Hi,Thanks a lot! Can confirm the authenticity of both patches. I also do not mind whether my full name or nickname is used, whatever is easier.Best regards,Vitaly On Thu, Jul 30, 2020 at 22:35, Michael S. Tsirkin wrote: On Thu, Jul 30, 2020 at 06:11:17PM +0200, Philippe

Re: [PATCH v2 1/2] virtio-mem: Change PRIx32 to PRIXPTR to fix compile error.

On 07/30/2020 09:15 PM, Philippe Mathieu-Daudé wrote: On 7/30/20 1:57 PM, Kaige Li wrote: When I compile qemu with such as: git clone https://git.qemu.org/git/qemu.git cd qemu git submodule init git submodule update --recursive ./configure make ^ this timeless description is pointless

[RFC PATCH v2 0/2] Add write-once and file-backed features to OTP

First patch is to add file-backed implementation to allow users to assign an OTP image file to machine. Users can assign the property, "otp-file", to machine to enable it. File-backed feature is set to "NULL" string in default. Any filename other than "NULL" is used as OTP image file. For

[RFC PATCH v2 2/2] hw/riscv: sifive_u: Add write-once protection.

Add array to store the 'written' status for all bit of OTP to block the write operation to the same bit. Ignore the control register offset from 0x0 to 0x38 of OTP memory mapping. Signed-off-by: Green Wan --- hw/riscv/sifive_u_otp.c | 20

Re: [PATCH 1/2] hw/net/net_tx_pkt: add function to check pkt->max_raw_frags

On 2020/7/31 上午1:05, Mauro Matteo Cascella wrote: On Thu, Jul 30, 2020 at 7:28 AM Jason Wang wrote: On 2020/7/29 上午12:26, Mauro Matteo Cascella wrote: On Tue, Jul 28, 2020 at 6:06 AM Jason Wang wrote: On 2020/7/28 上午1:08, Mauro Matteo Cascella wrote: This patch introduces a new function

Re: [PATCH v2 2/2] target/arm: Fix compile error.

On 07/31/2020 04:45 AM, Peter Maydell wrote: On Thu, 30 Jul 2020 at 12:58, Kaige Li wrote: When I compile qemu with such as: git clone https://git.qemu.org/git/qemu.git cd qemu git submodule init git submodule update --recursive ./configure make There is error log:

[PATCH V1 04/32] savevm: HMP Command for cprsave

Enable HMP access to the cprsave QMP command. Usage: cprsave Signed-off-by: Maran Wilson Signed-off-by: Steve Sistare --- hmp-commands.hx | 18 ++ include/monitor/hmp.h | 1 + monitor/hmp-cmds.c| 10 ++ 3 files changed, 29 insertions(+) diff --git

[PATCH V1 03/32] savevm: QMP command for cprsave

To enable live reboot, provide the cprsave QMP command and the VMS_REBOOT vmstate-saving operation, which saves the state of the virtual machine in a simple file. Syntax: {'command':'cprsave', 'data':{'file':'str', 'mode':'str'}} The mode argument must be 'reboot'. Additional modes will be

[PATCH V1 01/32] savevm: add vmstate handler iterators

Provide the SAVEVM_FOREACH and SAVEVM_FORALL macros to loop over all save VM state handlers. The former will filter handlers based on the operation in the later patch "savevm: VM handlers mode mask". The latter loops over all handlers. No functional change. Signed-off-by: Steve Sistare ---

[PATCH V1 08/32] savevm: HMP command for cprinfo

Enable HMP access to the cprinfo QMP command. Usage: cprinfo Signed-off-by: Steve Sistare --- hmp-commands.hx | 13 + include/monitor/hmp.h | 1 + monitor/hmp-cmds.c| 10 ++ 3 files changed, 24 insertions(+) diff --git a/hmp-commands.hx b/hmp-commands.hx index

[PATCH V1 32/32] vfio-pci: improved tracing

Print more info for existing trace points: trace_kvm_irqchip_add_msi_route. trace_pci_update_mappings_del trace_pci_update_mappings_add Add new trace points: trace_kvm_irqchip_assign_irqfd trace_msix_table_mmio_write trace_vfio_dma_unmap trace_vfio_dma_map trace_vfio_region

[PATCH V1 07/32] savevm: QMP command for cprinfo

Provide the cprinfo QMP command. This returns a string with a space- separated list of modes supported by cprsave, and can be used by clients as a feature test to check if the running QEMU instance supports cprsave. Syntax: {'command':'cprinfo', 'returns':'str'} Signed-off-by: Steve Sistare

[PATCH V1 16/32] oslib: add qemu_clr_cloexec

Signed-off-by: Steve Sistare --- include/qemu/osdep.h | 1 + util/oslib-posix.c | 9 + util/oslib-win32.c | 4 3 files changed, 14 insertions(+) diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h index 45c217a..bb28df1 100644 --- a/include/qemu/osdep.h +++

[PATCH V1 22/32] char: qio_channel_socket_accept reuse fd

From: Mark Kanda Add an fd argument to qio_channel_socket_accept. If not -1, the channel uses that fd instead of accepting a new socket connection. All callers pass -1 in this patch, so no functional change. Signed-off-by: Mark Kanda Signed-off-by: Steve Sistare ---

[Bug 1884684] Re: QEMU 5.0: Guest VM hangs/freeze when unplugging USB device

Following reports on Proxmox forums, this is still very much seen by multiple users with no known workaround. I was able to run QEMU 5.0.13 (Debian) with all traces turned on and capture the following: - Behavior is reproducible by unbinding usb device on the host (ex. "echo '1-8' >

[PATCH V1 28/32] char: restore terminal on restart

If stdin is is a char backend device, then restore original stdin terminal settings in before re-exec'ing. Otherwise, the new qemu sees the modified settings as initial settings, and does not restore the true initial settings when it exits. Signed-off-by: Steve Sistare --- chardev/char-stdio.c

[PATCH V1 25/32] char: save/restore chardev pty fds

Save and restore pty descriptors across cprsave and cprload. Signed-off-by: Steve Sistare --- chardev/char-pty.c | 38 +++--- chardev/char.c | 2 ++ include/chardev/char.h | 1 + 3 files changed, 30 insertions(+), 11 deletions(-) diff --git

[PATCH V1 30/32] vfio-pci: save and restore

Enable vfio-pci devices to be saved and restored across an exec restart of qemu. At vfio creation time, save the value of vfio container, group, and device descriptors in the environment. In cprsave, save the msi message area as part of vfio-pci vmstate, and clear the close-on-exec flag for the

[PATCH 2/2] arm/acpi: fix an out of spec _UID for PCI root

On ARM/virt machine type QEMU currently reports an incorrect _UID in ACPI. The particular node in question is the primary PciRoot (PCI0 in ACPI), which gets assigned PCI0 in ACPI UID and 0 in the DevicePath. This is due to the _UID assigned to it by build_dsdt in hw/arm/virt-acpi-build.c Which

Re: [PATCH 0/1] RFC: pcie: parital fix for missing unplug events

On Wed, Jul 22, 2020 at 07:17:21PM +0300, Maxim Levitsky wrote: > As described in bugzilla #1854264 it is possible to plug > a pcie device and then unplug it before the guest notices > (has time to process the attention button press) > > To partially fix this issue, detect and refuse the

Re: [PATCH 1/2] i386/acpi: fix inconsistent QEMU/OVMF device paths

On 7/30/20 5:58 PM, Michael S. Tsirkin wrote: > macOS uses ACPI UIDs to build the DevicePath for NVRAM boot options, > while OVMF firmware gets them via an internal channel through QEMU. > Due to a bug in QEMU ACPI currently UEFI firmware and ACPI have > different values, and this makes the

Re: [PATCH V1 03/32] savevm: QMP command for cprsave

On 7/30/20 10:14 AM, Steve Sistare wrote: To enable live reboot, provide the cprsave QMP command and the VMS_REBOOT vmstate-saving operation, which saves the state of the virtual machine in a simple file. Syntax: {'command':'cprsave', 'data':{'file':'str', 'mode':'str'}} The mode

Re: [PATCH 2/2] arm/acpi: fix an out of spec _UID for PCI root

On 7/30/20 5:58 PM, Michael S. Tsirkin wrote: > On ARM/virt machine type QEMU currently reports an incorrect _UID in > ACPI. > > The particular node in question is the primary PciRoot (PCI0 in ACPI), > which gets assigned PCI0 in ACPI UID and 0 in the > DevicePath. This is due to the _UID

Re: [PATCH V1 05/32] savevm: QMP command for cprload

On 7/30/20 10:14 AM, Steve Sistare wrote: Provide the cprload QMP command. The VM is created from the file produced by the cprsave command. Guest RAM is restored in-place from the shared memory backend file, and guest block devices are used as is. The contents of such devices must not be

  1   2   3   >