This adds GRAPH_RDLOCK annotations to declare that callers of
bdrv_co_block_status() need to hold a reader lock for the graph.
For some places, we know that they will hold the lock, but we don't have
the GRAPH_RDLOCK annotations yet. In this case, add assume_graph_lock()
with a FIXME comment. Thes
From: Emanuele Giuseppe Esposito
This adds GRAPH_RDLOCK annotations to declare that callers of
bdrv_co_copy_range() need to hold a reader lock for the graph.
Signed-off-by: Emanuele Giuseppe Esposito
Signed-off-by: Kevin Wolf
---
include/block/block-io.h | 9 +
include/block/
This adds GRAPH_RDLOCK annotations to declare that callers of
bdrv_*_dirty_bitmap() need to hold a reader lock for the graph.
Signed-off-by: Kevin Wolf
---
include/block/block-io.h | 14 ++
include/block/block_int-common.h | 6 --
include/block/dirty-bitmap.h | 12 ++
This adds GRAPH_RDLOCK annotations to declare that callers of
bdrv_co_create() need to hold a reader lock for the graph.
Signed-off-by: Emanuele Giuseppe Esposito
Signed-off-by: Kevin Wolf
---
include/block/block-global-state.h | 14 ---
include/block/block_int-common.h | 11 +++---
block
This adds GRAPH_RDLOCK annotations to declare that callers of
bdrv_register_buf() and bdrv_unregister_buf() need to hold a reader lock
for the graph.
Signed-off-by: Kevin Wolf
---
include/block/block_int-common.h | 7 ---
block/io.c | 14 ++
2 files changed
From: Emanuele Giuseppe Esposito
This adds GRAPH_RDLOCK annotations to declare that callers of
bdrv_co_flush() need to hold a reader lock for the graph.
For some places, we know that they will hold the lock, but we don't have
the GRAPH_RDLOCK annotations yet. In this case, add assume_graph_lock(
This adds GRAPH_RDLOCK annotations to declare that callers of
bdrv_co_pwrite_zeroes() need to hold a reader lock for the graph.
For some places, we know that they will hold the lock, but we don't have
the GRAPH_RDLOCK annotations yet. In this case, add assume_graph_lock()
with a FIXME comment. The
This adds GRAPH_RDLOCK annotations to declare that callers of
bdrv_driver_*() need to hold a reader lock for the graph. It doesn't add
the annotation to public functions yet.
For some places, we know that they will hold the lock, but we don't have
the GRAPH_RDLOCK annotations yet. In this case, ad
From: Emanuele Giuseppe Esposito
This adds GRAPH_RDLOCK annotations to declare that callers of
bdrv_co_is_inserted() need to hold a reader lock for the graph.
blk_is_inserted() is done as a co_wrapper_mixed_bdrv_rdlock (unlike most
other blk_* functions) because it is called a lot from other blk
This adds GRAPH_RDLOCK annotations to declare that callers of
bdrv_co_pread*/pwrite*() need to hold a reader lock for the graph.
For some places, we know that they will hold the lock, but we don't have
the GRAPH_RDLOCK annotations yet. In this case, add assume_graph_lock()
with a FIXME comment. Th
On Fri, 3 Feb 2023 at 08:45, Markus Armbruster wrote:
>
>
> The following changes since commit deabea6e88f7c4c3c12a36ee30051c6209561165:
>
> Merge tag 'for_upstream' of
> https://git.kernel.org/pub/scm/virt/kvm/mst/qemu into staging (2023-02-02
> 10:10:07 +)
>
> are available in the Git re
Hi Phil,
On Fri, Feb 03, 2023 at 04:02:16PM +0100, Philippe Mathieu-Daudé wrote:
> Hi Bastian,
>
> On 3/2/23 15:54, Bastian Koppelmann wrote:
> > since binutils is pretty old, it fails our CI repeatedly during the
> > compilation of tricore-binutils. We created a precompiled version using
> > the
On Fri, 2023-02-03 at 15:40 +0100, Pierre Morel wrote:
>
> On 2/3/23 14:22, Nina Schoetterl-Glausch wrote:
> > On Fri, 2023-02-03 at 10:21 +0100, Pierre Morel wrote:
> > >
> > > On 2/2/23 17:42, Nina Schoetterl-Glausch wrote:
> > > > On Wed, 2023-02-01 at 14:20 +0100, Pierre Morel wrote:
> > > >
On 03/02/2023 13.08, Kevin Wolf wrote:
Am 03.02.2023 um 12:23 hat Thomas Huth geschrieben:
On 30/01/2023 11.58, Daniel P. Berrangé wrote:
On Mon, Jan 30, 2023 at 11:44:46AM +0100, Thomas Huth wrote:
We can get rid of the build-coroutine-sigaltstack job by moving
the configure flags that should
On Fri, 3 Feb 2023 at 15:44, Thomas Huth wrote:
>
> On 03/02/2023 13.08, Kevin Wolf wrote:
> > Am 03.02.2023 um 12:23 hat Thomas Huth geschrieben:
> >> On 30/01/2023 11.58, Daniel P. Berrangé wrote:
> >>> On Mon, Jan 30, 2023 at 11:44:46AM +0100, Thomas Huth wrote:
> We can get rid of the bui
Philippe Mathieu-Daudé writes:
> Hi Bastian,
>
> On 3/2/23 15:54, Bastian Koppelmann wrote:
>> since binutils is pretty old, it fails our CI repeatedly during the
>> compilation of tricore-binutils. We created a precompiled version using
>> the debian docker image and download it instead of bui
Commit 3efa6fa1e62 "hw/loongarch: Add smbios support" enabled
CONFIG_SMBIOS for target loongarch64, by adding
select SMBIOS
to hw/loongarch/Kconfig.
It didn't enable CLI option -smbios in
qemu-options.hx. It's enabled for the other targets that have
CONFIG_SMBIOS.
Was this an oversight? I
On Fri, 3 Feb 2023, Philippe Mathieu-Daudé wrote:
Note this device doesn't implement unrealize().
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: BALATON Zoltan
---
hw/display/sm501.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/hw/display/sm501.
On Fri, 3 Feb 2023, Philippe Mathieu-Daudé wrote:
No need to use an intermediate 'dma-offset' property in the
chipset object. Alias the property, so when the machine (here
r2d-plus) sets the value on the chipset, it is propagated to
the OHCI object.
Note we can rename the chipset 'base' property
On Fri, 3 Feb 2023, Philippe Mathieu-Daudé wrote:
Since now PCI and SysBus properties are identical, unify them.
Suggested-by: BALATON Zoltan
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: BALATON Zoltan
---
hw/display/sm501.c | 11 +++
1 file changed, 3 insertions(+), 8 deleti
Richard Henderson writes:
> On 2/2/23 08:59, Alex Bennée wrote:
>>> +- env NINJA_STATUS="[ninja][%f/%t] " ninja | fgrep -v "[ninja]"
>>> - if test -n "$MAKE_CHECK_ARGS";
>>> then
>>> make -j"$JOBS" $MAKE_CHECK_ARGS ;
>> This is too much for gitlab as it trips up on n
Thomas Huth writes:
> On 02/02/2023 19.59, Alex Bennée wrote:
>> Alex Bennée writes:
>>
>>> A significant portion of our CI logs are just enumerating each
>>> successfully built object file. The current widespread versions of
>>> ninja don't have a quiet option so we use NINJA_STATUS to add a
No logical change, rename for clarity.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/acpi/acpi-cpu-hotplug-stub.c | 2 +-
hw/acpi/cpu_hotplug.c | 10 +-
hw/acpi/piix4.c | 10 +-
include/hw/acpi/cpu_hotplug.h | 2 +-
4 files changed, 12 insertions(+),
To ease code review, rename ACPI CPU hotplug variables
to more meaningful names.
Since hotplug parent can't be any QOM object, and must be
a QDev, convert AcpiCpuHotplug::device from Object* to
DeviceState*.
Philippe Mathieu-Daudé (3):
hw/acpi/cpu_hotplug: Rename gpe_cpu -> gpe
hw/acpi/cpu_ho
ACPI CPU hotplug parent can't be any QOM object, it must be a QDev.
Convert AcpiCpuHotplug::device field as QDev to enforce this.
Rename 'owner' and 'device' variables as 'parent'.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/acpi/acpi-cpu-hotplug-stub.c | 2 +-
hw/acpi/cpu_hotplug.c
Rename 'g' and 'gpe_cpu' variables as 'gpe' to simplify.
No logical change.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/acpi/acpi-cpu-hotplug-stub.c | 6 ++---
hw/acpi/cpu_hotplug.c | 40 -
hw/acpi/ich9.c | 8 +++
hw/acpi/piix4.c
> -Original Message-
> From: Christian Schoenebeck
> Sent: Friday, February 3, 2023 22:41
> To: Greg Kurz ; qemu-devel@nongnu.org
> Cc: Meng, Bin ; Marc-André Lureau
> ; Daniel P. Berrangé ; Shi,
> Guohuai
> Subject: Re: [PATCH v4 04/16] hw/9pfs: Implement Windows specific xxxdir()
> A
On 2/3/23 04:00, Vladimir Isaev wrote:
According to spec, ctzw should work with 32-bit register, not 64.
For example, previous implementation returns 33 for (1<<33) input
when the new one returns 32.
Signed-off-by: Vladimir Isaev
---
target/riscv/insn_trans/trans_rvb.c.inc | 9 -
1
On Thu, Jan 26, 2023 at 06:24:31PM +0100, Kevin Wolf wrote:
> bdrv_co_create_opts_simpl() runs in a coroutine. Therefore it is not
simple
> allowed to open images directly. Fix the call to use the corresponding
> no_co_wrapper instead.
>
> Signed-off-by: Kevin Wolf
> ---
> block.c | 4 ++--
>
After commit 4e4fa6c12d ("accel/tcg: Complete cpu initialization
before registration"), it looks the CPUJumpCache handle can be NULL.
This causes a SIGSEV when running debug-wp-migration kvm unit test.
At the first place it should be clarified why this TCG code is called
with KVM acceleration. Thi
Many registers whose 'cooked' writefns induce TLB maintenance do
not have raw_writefn ops defined. If only the writefn ops is set
(ie. no raw_writefn is provided), it is assumed the cooked also
work as the raw one. For those registers it is not obvious the
tlb_flush works on KVM mode so better/safe
'offset' should be bits [23:5] of LDR instruction, rather than [4:0].
Fixes: d59d83a1c388 ("tcg/aarch64: Reorg goto_tb implementation")
Reported-by: Zenghui Yu
Signed-off-by: Richard Henderson
---
tcg/aarch64/tcg-target.c.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t
On 3/2/23 18:15, Eric Auger wrote:
After commit 4e4fa6c12d ("accel/tcg: Complete cpu initialization
before registration"), it looks the CPUJumpCache handle can be NULL.
This causes a SIGSEV when running debug-wp-migration kvm unit test.
Do you mean commit a976a99a29 ("include/hw/core: Create st
Hi Philippe,
On 2/3/23 18:21, Philippe Mathieu-Daudé wrote:
> On 3/2/23 18:15, Eric Auger wrote:
>> After commit 4e4fa6c12d ("accel/tcg: Complete cpu initialization
>> before registration"), it looks the CPUJumpCache handle can be NULL.
>> This causes a SIGSEV when running debug-wp-migration kvm un
On 3/2/23 18:18, Richard Henderson wrote:
'offset' should be bits [23:5] of LDR instruction, rather than [4:0].
Fixes: d59d83a1c388 ("tcg/aarch64: Reorg goto_tb implementation")
Reported-by: Zenghui Yu
Signed-off-by: Richard Henderson
---
tcg/aarch64/tcg-target.c.inc | 2 +-
1 file changed,
On 2/3/23 01:23, Alex Bennée wrote:
Anton Johansson writes:
Hi,
I was running check-tcg with ASan enabled on master, and ran into
the following use-after-free. There appears to be a race between
jump cache invalidation and thread destruction (?)
I thought I'd post here since I noticed some
On Wed, 2023-02-01 at 14:20 +0100, Pierre Morel wrote:
> > On interception of STSI(15.1.x) the System Information Block
> > (SYSIB) is built from the list of pre-ordered topology entries.
> >
> > Signed-off-by: Pierre Morel
> > ---
> > include/hw/s390x/cpu-topology.h | 22 +++
> > include/hw/s3
On 2/3/23 07:25, Philippe Mathieu-Daudé wrote:
On 3/2/23 18:18, Richard Henderson wrote:
'offset' should be bits [23:5] of LDR instruction, rather than [4:0].
Fixes: d59d83a1c388 ("tcg/aarch64: Reorg goto_tb implementation")
Reported-by: Zenghui Yu
Signed-off-by: Richard Henderson
---
tcg/a
On 2/2/23 17:01, Alex Bennée wrote:
The following changes since commit 026817fb69414c9d3909d8b1a209f90180d777d6:
Merge tag 'python-pull-request' of https://gitlab.com/jsnow/qemu into
staging (2023-02-01 16:15:56 +)
are available in the Git repository at:
https://gitlab.com/stsquad/q
On Friday, February 3, 2023 5:30:35 PM CET Shi, Guohuai wrote:
>
> > -Original Message-
> > From: Christian Schoenebeck
> > Sent: Friday, February 3, 2023 22:41
> > To: Greg Kurz ; qemu-devel@nongnu.org
> > Cc: Meng, Bin ; Marc-André Lureau
> > ; Daniel P. Berrangé ;
> > Shi,
> > Guohuai
Hi Jason,
On 2/3/23 13:51, Jason Gunthorpe wrote:
> On Tue, Jan 31, 2023 at 09:53:05PM +0100, Eric Auger wrote:
>> Now we support two types of iommu backends, let's add the capability
>> to select one of them. This depends on whether an iommufd object has
>> been linked with the vfio-pci device:
>
On Fri, Feb 03, 2023 at 06:57:02PM +0100, Eric Auger wrote:
> Hi Jason,
>
> On 2/3/23 13:51, Jason Gunthorpe wrote:
> > On Tue, Jan 31, 2023 at 09:53:05PM +0100, Eric Auger wrote:
> >> Now we support two types of iommu backends, let's add the capability
> >> to select one of them. This depends on
On Fri, 3 Feb 2023 at 17:17, Eric Auger wrote:
>
> Many registers whose 'cooked' writefns induce TLB maintenance do
> not have raw_writefn ops defined. If only the writefn ops is set
> (ie. no raw_writefn is provided), it is assumed the cooked also
> work as the raw one. For those registers it is
On 2/3/23 13:57, Jason Gunthorpe wrote:
> On Tue, Jan 31, 2023 at 09:52:47PM +0100, Eric Auger wrote:
>> Given some iommufd kernel limitations, the iommufd backend is
>> not yuet fully on par with the legacy backend w.r.t. features like:
>> - p2p mappings (you will see related error traces)
>> -
Hi Peter,
On 2/3/23 19:04, Peter Maydell wrote:
> On Fri, 3 Feb 2023 at 17:17, Eric Auger wrote:
>> Many registers whose 'cooked' writefns induce TLB maintenance do
>> not have raw_writefn ops defined. If only the writefn ops is set
>> (ie. no raw_writefn is provided), it is assumed the cooked al
On 2/3/23 07:34, Richard Henderson wrote:
On 2/3/23 01:23, Alex Bennée wrote:
Anton Johansson writes:
Hi,
I was running check-tcg with ASan enabled on master, and ran into
the following use-after-free. There appears to be a race between
jump cache invalidation and thread destruction (?)
I
QEMU provides the QOM API for core objects.
Devices are modelled on top of QOM as QDev objects.
There is no point in using the lower level QOM API with
QDev; it makes the code more complex and harder to review.
I first converted all the calls using errp=&error_abort or
&errp=NULL, then noticed th
No need to use the low-level QOM API when an object
inherits from QDev. Directly use the QDev API to set
its properties.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/acpi/cpu_hotplug.c | 7 +++
hw/acpi/ich9.c| 4 ++--
hw/acpi/piix4.c | 4 ++--
3 files changed, 7 insertions(+),
No need to use the low-level QOM API when an object
inherits from QDev. Directly use the QDev API to set
its properties.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/audio/pcspk.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/hw/audio/pcspk.h b/include/hw/au
Introduce qdev_prop_set_link(), equivalent of
object_property_set_link() for QDev objects.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/core/qdev-properties.c| 5 +
include/hw/qdev-properties.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/hw/core/qdev-properties.c b/hw/core/qdev
No need to use the low-level QOM API when an object
inherits from QDev. Directly use the QDev API to set
its properties.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/avr/arduino.c | 4 ++--
hw/avr/atmega.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/avr/arduino.c
No need to use the low-level QOM API when an object
inherits from QDev. Directly use the QDev API to set
its properties.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/core/gpio.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/core/gpio.c b/hw/core/gpio.c
index 80d0
No need to use the low-level QOM API when an object
inherits from QDev. Directly use the QDev API to set
its properties.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/microblaze/petalogix_ml605_mmu.c | 40 +++-
hw/microblaze/petalogix_s3adsp1800_mmu.c | 2 +-
hw/microbla
No need to use the low-level QOM API when an object
inherits from QDev. Directly use the QDev API to set
its properties.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/riscv/microchip_pfsoc.c | 8
hw/riscv/opentitan.c | 9 +++--
hw/riscv/shakti_c.c| 7 +++
hw/risc
No need to use the low-level QOM API when an object
inherits from QDev. Directly use the QDev API to set
its properties.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/core/numa.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/core/numa.c b/hw/core/numa.c
index d8d36b16
No need to use the low-level QOM API when an object
inherits from QDev. Directly use the QDev API to set
its properties.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/hppa/machine.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
index d
No need to use the low-level QOM API when an object
inherits from QDev. Directly use the QDev API to set
its properties.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/mips/boston.c | 6 ++
hw/mips/cps.c| 42 ++
hw/mips/jazz.c | 3 +--
hw/mips/ma
No need to use the low-level QOM API when an object
inherits from QDev. Directly use the QDev API to set
its properties.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/display/virtio-gpu-pci.c | 4 ++--
hw/display/virtio-vga.c | 4 ++--
hw/virtio/virtio-iommu-pci.c | 3 +--
hw/virtio/virtio-
No need to use the low-level QOM API when an object
inherits from QDev. Directly use the QDev API to set
its properties.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/pc.c | 8 +++-
hw/i386/pc_q35.c | 25 +++--
hw/i386/sgx.c | 3 +--
hw/i386
No need to use the low-level QOM API when an object
inherits from QDev. Directly use the QDev API to set
its properties.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/dma/sparc32_dma.c | 6 +++---
hw/sparc/sun4m.c | 10 --
hw/sparc64/sun4u.c | 3 +--
3 files changed, 8 insertions(
Script I used to generate the following patches. This is
not an automatic conversion as object_property_set_[u]int()
does not specify the type size. Each integer property must
then be converted manually. Therefore this script doesn't
seem relevant to be committed in the repository.
Signed-off-by:
No need to use the low-level QOM API when an object
inherits from QDev. Directly use the QDev API to set
its properties.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/nios2/10m50_devboard.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/nios2/10m50_devboard.c b/hw/nios2/10
No need to use the low-level QOM API when an object
inherits from QDev. Directly use the QDev API to set
its properties.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/m68k/next-cube.c | 2 +-
hw/m68k/q800.c | 7 +++
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/hw/m68k/n
On 3/2/23 19:08, Philippe Mathieu-Daudé wrote:
QEMU provides the QOM API for core objects.
Devices are modelled on top of QOM as QDev objects.
There is no point in using the lower level QOM API with
QDev; it makes the code more complex and harder to review.
I first converted all the calls using
No need to use the low-level QOM API when an object
inherits from QDev. Directly use the QDev API to set
its properties.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/rx/rx-gdbsim.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/hw/rx/rx-gdbsim.c b/hw/rx/rx-gdbsim
No need to use the low-level QOM API when an object
inherits from QDev. Directly use the QDev API to set
its properties.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/usb/hcd-xhci-pci.c| 2 +-
hw/usb/hcd-xhci-sysbus.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/u
No need to use the low-level QOM API when an object
inherits from QDev. Directly use the QDev API to set
its properties.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/scsi/scsi-bus.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/hw/scsi/scsi-bus.c b/hw/scsi/scsi-bus.c
i
The two TCG tests for GICv2 and GICv3 are very heavy weight distros
that take a long time to boot up, especially for an --enable-debug
build. The total code coverage they give is:
Overall coverage rate:
lines..: 11.2% (59584 of 530123 lines)
functions..: 15.0% (7436 of 49443 function
Newer versions of pylint disable the "no-self-use" message by
default. Older versions don't, though. If we leave the suppressions in,
pylint yelps about useless options. Just tell pylint to shush.
Signed-off-by: John Snow
---
scripts/qapi/pylintrc | 1 +
1 file changed, 1 insertion(+)
diff --gi
New versions of flake8 don't like same-line comments. (It's a version
newer than what fc37 ships, but it still makes my life easier to fix it
now.)
Signed-off-by: John Snow
---
scripts/qapi/.flake8 | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/qapi/.flake8 b/scrip
This is just POC to prove that the docstrings, where they are written,
are correct to some minimum standard. It is included here for
reviewing/testing convenience.
Signed-off-by: John Snow
---
docs/conf.py | 3 ++-
docs/devel/index.rst | 1 +
docs/deve
These aren't ready for upstream inclusion, because they do not properly
manage version dependencies, execution environment and so on. These are
just the tools I use in my Own Special Environment :tm: for testing and
debugging.
They've been tested only on Fedora 37 for right now, which means:
Pyth
This is a manual testing pre-requisite for other QAPI cleanup
patches. It isn't meant for inclusion, it's included here as an
informative basis for ongoing work only.
(Except for the last two patches, which you should totally merge.)
sphinx-autodoc is enabled for the scripts/qapi package so that
ilable in the Git repository at:
>
> https://git.linaro.org/people/pmaydell/qemu-arm.git
> tags/pull-target-arm-20230203
>
> for you to fetch changes up to bb18151d8bd9bedc497ee9d4e8d81b39a4e5bbf6:
>
> target/arm: Enab
On Fri, 3 Feb 2023, Philippe Mathieu-Daudé wrote:
On 3/2/23 19:08, Philippe Mathieu-Daudé wrote:
QEMU provides the QOM API for core objects.
Devices are modelled on top of QOM as QDev objects.
There is no point in using the lower level QOM API with
QDev; it makes the code more complex and harde
Since some actions move to the start function instead of init, the
device features may not be the parent vdpa device's, but the one
returned by vhost backend. If transition to SVQ is supported, the vhost
backend will return _F_LOG_ALL to signal the device is migratable.
Add VHOST_F_LOG_ALL. HW d
It's possible to migrate vdpa net devices if they are shadowed from the
start. But to always shadow the dataplane is to effectively break its host
passthrough, so its not convenient in vDPA scenarios.
This series enables dynamically switching to shadow mode only at
migration time. This allows fu
Next patches enable devices to be migrated even if vdpa netdev has not
been started with x-svq. However, not all devices are migratable, so we
need to block migration if we detect that.
Block vhost-vdpa device migration if it does not offer _F_SUSPEND and it
has not been started with x-svq.
Signe
This is needed for qemu to know it can suspend the device to retrieve
its status and enable SVQ with it, so all the process is transparent to
the guest.
Signed-off-by: Eugenio Pérez
Acked-by: Jason Wang
---
hw/virtio/vhost-vdpa.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --g
vhost-vdpa devices can return this features now that blockers have been
set in case some features are not met.
Expose VHOST_F_LOG_ALL only in that case.
Signed-off-by: Eugenio Pérez
---
hw/virtio/vhost-vdpa.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/hw/virtio/vhost-
The function vhost.c:vhost_dev_stop fetches the vring base so the vq
state can be migrated to other devices. However, this is unreliable in
vdpa, since we didn't signal the device to suspend the queues, making
the value fetched useless.
Suspend the device if possible before fetching first and sub
This allows net to restart the device backend to configure SVQ on it.
Ideally, these changes should not be net specific. However, the vdpa net
backend is the one with enough knowledge to configure everything because
of some reasons:
* Queues might need to be shadowed or not depending on its kind (
Only create iova_tree if and when it is needed.
The cleanup keeps being responsible of last VQ but this change allows it
to merge both cleanup functions.
Signed-off-by: Eugenio Pérez
Acked-by: Jason Wang
---
net/vhost-vdpa.c | 99 ++--
1 file changed
Devices with CVQ needs to migrate state beyond vq state. Leaving this
to future series.
Signed-off-by: Eugenio Pérez
---
net/vhost-vdpa.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/net/vhost-vdpa.c b/net/vhost-vdpa.c
index bca13f97fd..309861e56c 100644
--- a/net/vhost-vdpa.c
+++
A vdpa net device must initialize with SVQ in order to be migratable at
this moment, and initialization code verifies some conditions. If the
device is not initialized with the x-svq parameter, it will not expose
_F_LOG so the vhost subsystem will block VM migration from its
initialization.
Next
The function vhost.c:vhost_dev_stop calls vhost operation
vhost_dev_start(false). In the case of vdpa it totally reset and wipes
the device, making the fetching of the vring base (virtqueue state) totally
useless.
The kernel backend does not use vhost_dev_start vhost op callback, but
vhost-user do
At this moment it is only possible to migrate to a vdpa device running
with x-svq=on. As a protective measure, the rewind of the inflight
descriptors was done at the destination. That way if the source sent a
virtqueue with inuse descriptors they are always discarded.
Since this series allows to m
Next patches enable devices to be migrated even if vdpa netdev has not
been started with x-svq. However, not all devices are migratable, so we
need to block migration if we detect that.
Block migration if we detect the device expose a feature SVQ does not
know how to work with.
Signed-off-by: Eug
Although it does not make a big difference, its more correct and
simplifies the cleanup path in subsequent patches.
Move ram_block_discard_disable(false) call to the top of
vhost_vdpa_cleanup because:
* We cannot use vhost_vdpa_first_dev after dev->opaque = NULL
assignment.
* Improve the stack o
On 2/3/23 03:44, Cornelia Huck wrote:
Just use current_accel_name() directly.
Signed-off-by: Cornelia Huck
---
hw/arm/virt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Reviewed-by: Richard Henderson
r~
Reported-by: Stefan Weil
Signed-off-by: BALATON Zoltan
---
hw/ppc/pegasos2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/ppc/pegasos2.c b/hw/ppc/pegasos2.c
index 1a13632ba6..a9563f4fb2 100644
--- a/hw/ppc/pegasos2.c
+++ b/hw/ppc/pegasos2.c
@@ -564,7 +564,7 @@ static vo
Jiang Jiacheng wrote:
> Introduce interface query-migrationthreads. The interface is used
> to query information about migration threads and returns with
> migration thread's name and its id.
> Introduce threadinfo.c to manage threads with migration.
>
> Signed-off-by: Jiang Jiacheng
Reviewed-by
Jiang Jiacheng wrote:
> To support query migration thread infomation, save and delete
> thread(live_migration and multifdsend) information at thread
> creation and finish.
>
> Signed-off-by: Jiang Jiacheng
Reviewed-by: Juan Quintela
Alex Bennée writes:
> The two TCG tests for GICv2 and GICv3 are very heavy weight distros
> that take a long time to boot up, especially for an --enable-debug
> build. The total code coverage they give is:
>
> Overall coverage rate:
> lines..: 11.2% (59584 of 530123 lines)
> functio
On 2/3/23 03:44, Cornelia Huck wrote:
+static void aarch64_cpu_get_mte(Object *obj, Visitor *v, const char *name,
+void *opaque, Error **errp)
+{
+ARMCPU *cpu = ARM_CPU(obj);
+OnOffAuto mte = cpu->prop_mte;
+
+visit_type_OnOffAuto(v, name, &mte, errp);
On 2/3/23 08:16, Alex Bennée wrote:
The two TCG tests for GICv2 and GICv3 are very heavy weight distros
that take a long time to boot up, especially for an --enable-debug
build. The total code coverage they give is:
Overall coverage rate:
lines..: 11.2% (59584 of 530123 lines)
f
On 3/2/23 20:43, BALATON Zoltan wrote:
Reported-by: Stefan Weil
Signed-off-by: BALATON Zoltan
---
hw/ppc/pegasos2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Philippe Mathieu-Daudé
Peter Xu wrote:
> On Thu, Feb 02, 2023 at 11:52:21AM +0100, Juan Quintela wrote:
>> Peter Xu wrote:
>> > Teach QEMU to use /dev/userfaultfd when it existed and fallback to the
>> > system call if either it's not there or doesn't have enough permission.
>> >
>> > Firstly, as long as the app has pe
Hey,
On 2/3/23 07:45, Bin Meng wrote:
Hi Daniel,
On Fri, Feb 3, 2023 at 6:31 PM Daniel Henrique Barboza
wrote:
On 2/3/23 02:39, Bin Meng wrote:
On Thu, Feb 2, 2023 at 9:58 PM Daniel Henrique Barboza
wrote:
load_elf_ram_sym() will sign-extend 32 bit addresses. If a 32 bit QEMU
guest hap
Kevin Wolf wrote:
> Am 03.02.2023 um 12:23 hat Thomas Huth geschrieben:
>> On 30/01/2023 11.58, Daniel P. Berrangé wrote:
>> > On Mon, Jan 30, 2023 at 11:44:46AM +0100, Thomas Huth wrote:
>> > > We can get rid of the build-coroutine-sigaltstack job by moving
>> > > the configure flags that should
201 - 300 of 338 matches
Mail list logo
