[PATCH v2 2/4] accel/kvm: Introduce kvm_create_and_park_vcpu() helper

There are distinct helpers for creating and parking a KVM vCPU. However, there can be cases where a platform needs to create and immediately park the vCPU during early stages of vcpu init which can later be reused when vcpu thread gets initialized. This would help detect failures with

[PATCH v2 3/4] cpu-common.c: export cpu_get_free_index to be reused later

This helper provides an easy way to identify the next available free cpu index which can be used for vcpu creation. Until now, this is being called at a very later stage and there is a need to be able to call it earlier (for now, with ppc64) hence the need to export. Suggested-by: Nicholas Piggin

[PATCH v2 1/4] accel/kvm: Extract common KVM vCPU {creation, parking} code

From: Salil Mehta KVM vCPU creation is done once during the vCPU realization when Qemu vCPU thread is spawned. This is common to all the architectures as of now. Hot-unplug of vCPU results in destruction of the vCPU object in QOM but the corresponding KVM vCPU object in the Host KVM is not

[PATCH v2 4/4] target/ppc: handle vcpu hotplug failure gracefully

On ppc64, the PowerVM hypervisor runs with limited memory and a VCPU creation during hotplug may fail during kvm_ioctl for KVM_CREATE_VCPU, leading to termination of guest since errp is set to _fatal while calling kvm_init_vcpu. This unexpected behaviour can be avoided by pre-creating and parking

[PATCH v2 0/4] target/ppc: vcpu hotplug failure handling fixes

On ppc64, the PowerVM hypervisor runs with limited memory and a VCPU creation during hotplug may fail during kvm_ioctl for KVM_CREATE_VCPU, leading to termination of guest since errp is set to _fatal while calling kvm_init_vcpu. This unexpected behaviour can be avoided by pre-creating and parking

Re: [PATCH] target/riscv: rvzicbo: Fixup CBO extension register calculation

On Tue, May 14, 2024 at 7:11 PM Daniel Henrique Barboza wrote: > > > > On 5/13/24 23:39, Alistair Francis wrote: > > When running the instruction > > > > ``` > > cbo.flush 0(x0) > > ``` > > > > QEMU would segfault. > > > > The issue was in cpu_gpr[a->rs1] as QEMU does not have cpu_gpr[0] > >

Re: [PATCH v11 08/10] virtio-gpu: Handle resource blob commands

On 2024/05/16 2:15, Dmitry Osipenko wrote: On 5/15/24 20:04, Akihiko Odaki wrote: VIRTIO_GPU_CMD_RESOURCE_UNREF should also call virtio_gpu_virgl_async_unmap_resource_blob(). I guess that's the original intention of having a function for this instead of inlining the content of this function

Re: [PATCH v2] target/riscv: Remove experimental prefix from "B" extension

On Tue, May 14, 2024 at 9:04 PM Rob Bradford wrote: > > This extension has now been ratified: > https://jira.riscv.org/browse/RVS-2006 so the "x-" prefix can be > removed. > > Since this is now a ratified extension add it to the list of extensions > included in the "max" CPU variant. > >

Re: [PATCH v2] target/riscv: Remove experimental prefix from "B" extension

On Tue, May 14, 2024 at 9:04 PM Rob Bradford wrote: > > This extension has now been ratified: > https://jira.riscv.org/browse/RVS-2006 so the "x-" prefix can be > removed. > > Since this is now a ratified extension add it to the list of extensions > included in the "max" CPU variant. > >

Re: [PATCH] target/ppc: handle vcpu hotplug failure gracefully

Hi Nick, On 5/14/24 08:39, Nicholas Piggin wrote: On Tue Apr 23, 2024 at 4:30 PM AEST, Harsh Prateek Bora wrote: + qemu-devel On 4/23/24 11:40, Harsh Prateek Bora wrote: On ppc64, the PowerVM hypervisor runs with limited memory and a VCPU creation during hotplug may fail during kvm_ioctl for

Re: [PATCH v4 2/2] vhost-user: fix lost reconnect again

On Wed, May 15, 2024 at 10:58 PM Li Feng wrote: > > When the vhost-user is reconnecting to the backend, and if the vhost-user > fails > at the get_features in vhost_dev_init(), then the reconnect will fail > and it will not be retriggered forever. > > The reason is: > When the vhost-user fail at

Re: [PATCH v4 1/2] Revert "vhost-user: fix lost reconnect"

On Wed, May 15, 2024 at 10:58 PM Li Feng wrote: > > This reverts commit f02a4b8e6431598612466f76aac64ab492849abf. > > Since the current patch cannot completely fix the lost reconnect > problem, there is a scenario that is not considered: > - When the virtio-blk driver is removed from the guest

Re: [PATCH v3 2/2] vhost-user: fix lost reconnect again

OK - I'm happy with this approach then. On Wed, May 15, 2024 at 10:48 PM Li Feng wrote: > > > > 2024年5月15日 23:47，Raphael Norwitz 写道： > > The case your describing makes sense but now I have some concerns on > the vhost_dev_cleanup bit. > > On Wed, May 15, 2024 at 1:47 AM Li Feng wrote: > > > >

Re: [PATCH v3 5/5] virtio-gpu: fix v2 migration

On Wed, May 15, 2024 at 06:15:48PM +0100, Daniel P. Berrangé wrote: > On Wed, May 15, 2024 at 11:03:27AM -0600, Peter Xu wrote: > > On Wed, May 15, 2024 at 05:03:44PM +0100, Daniel P. Berrangé wrote: > > > Above all, I'm failing to see why there's a compelling reason > > > for virtio_gpu to

[PATCH v2 3/3] migration/colo: Tidy up bql_unlock() around bdrv_activate_all()

Make the code more tight. Suggested-by: Michael Tokarev Reviewed-by: Peter Xu Reviewed-by: Zhang Chen Signed-off-by: Li Zhijian --- V2: Collected reviewed-by tags This change/comment suggested by "Michael Tokarev " came a bit late at that time, let's update it together in these minor set this

[PATCH v2 2/3] migration/colo: make colo_incoming_co() return void

Currently, it always returns 0, no need to check the return value at all. In addition, enter colo coroutine only if migration_incoming_colo_enabled() is true. Once the destination side enters the COLO* state, the COLO process will take over the remaining processes until COLO exits. Cc: Fabiano

[PATCH v2 1/3] migration/colo: Minor fix for colo error message

- Explicitly show the missing module name: replication - Fix capability name to x-colo Reviewed-by: Peter Xu Reviewed-by: Zhang Chen Signed-off-by: Li Zhijian --- V2: Collected reviewed-by tags --- migration/migration.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

Re: [PATCH 2/3] migration/colo: make colo_incoming_co() return void

On 16/05/2024 03:04, Fabiano Rosas wrote: > Li Zhijian via writes: > >> Currently, it always returns 0, no need to check the return value at all. >> In addition, enter colo coroutine only if migration_incoming_colo_enabled() >> is true. >> Once the destination side enters the COLO* state, the

[PATCH v4 1/2] Revert "vhost-user: fix lost reconnect"

This reverts commit f02a4b8e6431598612466f76aac64ab492849abf. Since the current patch cannot completely fix the lost reconnect problem, there is a scenario that is not considered: - When the virtio-blk driver is removed from the guest os, s->connected has no chance to be set to false, resulting

[PATCH v4 2/2] vhost-user: fix lost reconnect again

When the vhost-user is reconnecting to the backend, and if the vhost-user fails at the get_features in vhost_dev_init(), then the reconnect will fail and it will not be retriggered forever. The reason is: When the vhost-user fail at get_features, the vhost_dev_cleanup will be called immediately.

Re: [PATCH 2/2] tests: add testing of parameter=1 for SMP topology

On 5/13/2024 8:33 PM, Daniel P. Berrangé wrote: Validate that it is possible to pass 'parameter=1' for any SMP topology parameter, since unsupported parameters are implicitly considered to always have a value of 1. Signed-off-by: Daniel P. Berrangé --- tests/unit/test-smp-parse.c | 8

Re: [PATCH v3 2/2] vhost-user: fix lost reconnect again

> 2024年5月15日 23:47，Raphael Norwitz 写道： > > The case your describing makes sense but now I have some concerns on > the vhost_dev_cleanup bit. > > On Wed, May 15, 2024 at 1:47 AM Li Feng > wrote: >> >> >> >>> 2024年5月14日 21:58，Raphael Norwitz 写道： >>> >>> Code

Re: [PATCH RFC v4 0/7] virtio-net: add support for SR-IOV emulation

On 2024/04/28 18:05, Akihiko Odaki wrote: Based-on: <20240315-reuse-v9-0-67aa69af4...@daynix.com> ("[PATCH for 9.1 v9 00/11] hw/pci: SR-IOV related fixes and improvements") Introduction This series is based on the RFC series submitted by Yui Washizu[1]. See also [2] for the

Re: [RFC PATCH-for-9.1 0/4] hw/i2c: Convert to spec v7 (inclusive) terminology

On Mon, Apr 08, 2024 at 11:33:34PM +0200, Philippe Mathieu-Daudé wrote: > Mechanical (mostly) conversion inspired by Wolfram [*] to > use inclusive terminology, similarly to the other renames > we did 3 years ago, shortly before the I2C spec v7 was > published. Sorry, I've been extremely busy on

Re: [PATCH v5 7/8] xen: mapcache: Add support for grant mappings

On Fri, 3 May 2024, Edgar E. Iglesias wrote: > From: "Edgar E. Iglesias" > > Add a second mapcache for grant mappings. The mapcache for > grants needs to work with XC_PAGE_SIZE granularity since > we can't map larger ranges than what has been granted to us. > > Like with foreign mappings

Re: [PATCH v5 6/8] xen: mapcache: Pass the ram_addr offset to xen_map_cache()

On Fri, 3 May 2024, Edgar E. Iglesias wrote: > From: "Edgar E. Iglesias" > > Pass the ram_addr offset to xen_map_cache. > This is in preparation for adding grant mappings that need > to compute the address within the RAMBlock. > > No functional changes. > > Signed-off-by: Edgar E. Iglesias >

Re: [PATCH v5 5/8] softmmu: Replace check for RAMBlock offset 0 with xen_mr_is_memory

On Fri, 3 May 2024, Edgar E. Iglesias wrote: > From: "Edgar E. Iglesias" > > For xen, when checking for the first RAM (xen_memory), use > xen_mr_is_memory() rather than checking for a RAMBlock with > offset 0. > > All Xen machines create xen_memory first so this has no > functional change for

Re: [PATCH v5 4/8] softmmu: xen: Always pass offset + addr to xen_map_cache

On Fri, 3 May 2024, Edgar E. Iglesias wrote: > From: "Edgar E. Iglesias" > > Always pass address with offset to xen_map_cache(). > This is in preparation for support for grant mappings. > > Since this is within a block that checks for offset == 0, > this has no functional changes. > >

Re: [PATCH 1/1] vhost-vsock: add VIRTIO_F_RING_PACKED to feaure_bits

On Tue, 7 May 2024 21:26:30 +0200 Halil Pasic wrote: > > Not having VIRTIO_F_RING_PACKED in feature_bits[] is a problem when the > > vhost-vsock device does not offer the feature bit VIRTIO_F_RING_PACKED > > but the in QEMU device is configured to try to use the packed layout > > (the virtio

Re: [PATCH v2 02/11] qcow2: simplify L2 entries accounting for discard-no-unref

On Mon 13 May 2024 09:31:54 AM +03, Andrey Drobyshev wrote: > Commits 42a2890a and b2b10904 introduce handling of discard-no-unref > option in discard_in_l2_slice() and zero_in_l2_slice(). They add even > more if's when chosing the right l2 entry. What we really need for this > option is the new

Re: [PATCH v2 01/11] qcow2: make function update_refcount_discard() global

On Mon 13 May 2024 09:31:53 AM +03, Andrey Drobyshev wrote: > We are going to need it for discarding separate subclusters. The > function itself doesn't do anything with the refcount tables, it simply > adds a discard request to the queue, so rename it to qcow2_queue_discard(). > > Signed-off-by:

Re: [PATCH v3 5/5] virtio-gpu: fix v2 migration

On Wed, May 15, 2024 at 10:31:32AM -0600, Peter Xu wrote: > On Wed, May 15, 2024 at 12:02:49PM -0400, Michael S. Tsirkin wrote: > > On Wed, May 15, 2024 at 06:15:56PM +0400, marcandre.lur...@redhat.com wrote: > > > From: Marc-André Lureau > > > > > > Commit dfcf74fa ("virtio-gpu: fix scanout

Re: [RFC PATCH v3 3/5] KVM: x86: Add notifications for Heki policy configuration and violation

On Tue, May 14, 2024, Mickaël Salaün wrote: > On Fri, May 10, 2024 at 10:07:00AM +, Nicolas Saenz Julienne wrote: > > Development happens > > https://github.com/vianpl/{linux,qemu,kvm-unit-tests} and the vsm-next > > branch, but I'd advice against looking into it until we add some order > > to

Re: [RFC PATCH v3 04/18] hw/arm/smmu: Use enum for SMMU stage

Mostafa Saleh writes: > Currently, translation stage is represented as an int, where 1 is stage-1 and > 2 is stage-2, when nested is added, 3 would be confusing to represent nesting, > so we use an enum instead. > > While keeping the same values, this is useful for: > - Doing tricks with bit

[PULL 03/11] plugins: prepare introduction of new inline ops

From: Pierrick Bouvier Until now, only add_u64 was available, and all functions assumed this or were named uniquely. Reviewed-by: Richard Henderson Signed-off-by: Pierrick Bouvier Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Michael S. Tsirkin Signed-off-by: Alex Bennée Message-Id:

[PULL 09/11] plugins: distinct types for callbacks

From: Pierrick Bouvier To prevent errors when writing new types of callbacks or inline operations, we split callbacks data to distinct types. Reviewed-by: Richard Henderson Signed-off-by: Pierrick Bouvier Message-Id: <20240502211522.346467-8-pierrick.bouv...@linaro.org> Reviewed-by: Michael

[PULL 07/11] plugins: conditional callbacks

From: Pierrick Bouvier Extend plugins API to support callback called with a given criteria (evaluated inline). Added functions: - qemu_plugin_register_vcpu_tb_exec_cond_cb - qemu_plugin_register_vcpu_insn_exec_cond_cb They expect as parameter a condition, a qemu_plugin_u64_t (op1) and an

[PULL 10/11] plugins: extract cpu_index generate

From: Pierrick Bouvier Factorizes function to access current cpu index for a given vcpu. Reviewed-by: Richard Henderson Signed-off-by: Pierrick Bouvier Message-Id: <20240502211522.346467-9-pierrick.bouv...@linaro.org> Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Michael S. Tsirkin

[PULL 01/11] tests/tcg: don't append QEMU_OPTS for armv6m-undef test

We don't want to build on the default machine setup here but define a custom one for the microbit. Reviewed-by: Pierrick Bouvier Reviewed-by: Michael S. Tsirkin Signed-off-by: Alex Bennée Message-Id: <20240514174253.694591-2-alex.ben...@linaro.org> diff --git

[PULL 00/11] testing and plugin updates

The following changes since commit 265aad58e9cab31d0e69c374ec2efcede7fa8881: Merge tag 'ui-pull-request' of https://gitlab.com/marcandre.lureau/qemu into staging (2024-05-15 08:52:27 +0200) are available in the Git repository at: https://gitlab.com/stsquad/qemu.git

[PULL 02/11] scripts/update-linux-header.sh: be more src tree friendly

Running "install_headers" in the Linux source tree is fairly unfriendly as out-of-tree builds will start complaining about the kernel source being non-pristine. As we have a temporary directory for the install we should also do the build step here. So now we have: $tmpdir/ $blddir/

[PULL 06/11] tests/plugin/inline: add test for STORE_U64 inline op

From: Pierrick Bouvier Reviewed-by: Richard Henderson Signed-off-by: Pierrick Bouvier Message-Id: <20240502211522.346467-5-pierrick.bouv...@linaro.org> Reviewed-by: Michael S. Tsirkin Signed-off-by: Alex Bennée Message-Id: <20240514174253.694591-7-alex.ben...@linaro.org> diff --git

[PULL 04/11] plugins: extract generate ptr for qemu_plugin_u64

From: Pierrick Bouvier Plugin operations can access a scoreboard. This function factorizes code generation for accessing entry associated to a given vcpu. Reviewed-by: Richard Henderson Signed-off-by: Pierrick Bouvier Message-Id: <20240502211522.346467-3-pierrick.bouv...@linaro.org>

[PULL 05/11] plugins: add new inline op STORE_U64

From: Pierrick Bouvier This new operation can store an immediate u64 value to a given scoreboard. Reviewed-by: Richard Henderson Signed-off-by: Pierrick Bouvier Message-Id: <20240502211522.346467-4-pierrick.bouv...@linaro.org> Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Michael S.

[PULL 08/11] tests/plugin/inline: add test for conditional callback

From: Pierrick Bouvier Count number of tb and insn executed using a conditional callback. We ensure the callback has been called expected number of time (per vcpu). Reviewed-by: Richard Henderson Signed-off-by: Pierrick Bouvier Message-Id: <20240502211522.346467-7-pierrick.bouv...@linaro.org>

[PULL 11/11] plugins: remove op from qemu_plugin_inline_cb

From: Pierrick Bouvier This field is not needed as the callback type already holds this information. Reviewed-by: Richard Henderson Signed-off-by: Pierrick Bouvier Message-Id: <20240502211522.346467-10-pierrick.bouv...@linaro.org> Reviewed-by: Michael S. Tsirkin Signed-off-by: Alex Bennée

Re: [PATCH 2/3] migration/colo: make colo_incoming_co() return void

Li Zhijian via writes: > Currently, it always returns 0, no need to check the return value at all. > In addition, enter colo coroutine only if migration_incoming_colo_enabled() > is true. > Once the destination side enters the COLO* state, the COLO process will > take over the remaining

RE: [PULL 00/11] Ui patches

Hi Marc-André, > -Original Message- > From: Marc-André Lureau > Sent: Wednesday, May 15, 2024 3:44 AM > To: Michael Tokarev > Cc: qemu-devel@nongnu.org; qemu-stable ; > hikalium ; Kim, Dongwon > Subject: Re: [PULL 00/11] Ui patches > > Hi > > On Wed, May 15, 2024 at 2:29 PM Michael

Re: [PATCH 03/20] docs/qapidoc: delint a tiny portion of the module

On Wed, May 15, 2024, 1:27 PM Markus Armbruster wrote: > John Snow writes: > > > On Wed, May 15, 2024 at 5:17 AM Markus Armbruster > wrote: > > > >> John Snow writes: > >> > >> > In the coming patches, it's helpful to have a linting baseline. > However, > >> > there's no need to shuffle

[PATCH v3 2/5] ppc/pnv: Extend SPI model

In this commit SPI shift engine and sequencer logic is implemented. Shift engine performs serialization and de-serialization according to the control by the sequencer and according to the setup defined in the configuration registers. Sequencer implements the main control logic and FSM to handle

[PATCH v3 5/5] tests/qtest: Add pnv-spi-seeprom qtest

In this commit Write a qtest pnv-spi-seeprom-test to check the SPI transactions between spi controller and seeprom device. Signed-off-by: Chalapathi V --- tests/qtest/pnv-spi-seeprom-test.c | 129 + tests/qtest/meson.build| 1 + 2 files changed, 130

[PATCH v3 4/5] hw/ppc: SPI controller wiring to P10 chip

In this commit, create SPI controller on p10 chip and connect cs irq. The QOM tree of spi controller and seeprom are. /machine (powernv10-machine) /chip[0] (power10_v2.0-pnv-chip) /pib_spic[2] (pnv-spi-controller) /pnv-spi-bus.2 (SSI) /xscom-spi-controller-regs[0]

[PATCH v3 0/5] hw/ppc: SPI model

Hello, Thank You so much for reviewing patch v2. In patch v3, most of Cedric's comments are addressed. - PnvSPIBus model is removed and added SSIBus to PnvSpiController. - Added trace-events and removed SPI_DEBUG macro. - Added Microchip's 25csm04 device on top of m25p80 and create seeprom

[PATCH v3 1/5] ppc/pnv: Add SPI controller model

SPI controller device model supports a connection to a single SPI responder. This provide access to SPI seeproms, TPM, flash device and an ADC controller. All SPI function control is mapped into the SPI register space to enable full control by firmware. In this commit SPI configuration component

[PATCH v3 3/5] hw/block: Add Microchip's 25CSM04 to m25p80

Add Microchip's 25CSM04 Serial EEPROM to m25p80. 25CSM04 provides 4 Mbits of Serial EEPROM utilizing the Serial Peripheral Interface (SPI) compatible bus. The device is organized as 524288 bytes of 8 bits each (512Kbyte) and is optimized for use in consumer and industrial applications where

[PATCH 2/4] gdbstub: Add support for MTE in user mode

This commit implements the stubs to handle the qIsAddressTagged, qMemTag, and QMemTag GDB packets, allowing all GDB 'memory-tag' subcommands to work with QEMU gdbstub on aarch64 user mode. It also implements the get/set function for the special GDB MTE register 'tag_ctl', used to control the MTE

[PATCH 4/4] tests/tcg/aarch64: Add MTE gdbstub tests

Add tests to exercise the MTE stubs. Signed-off-by: Gustavo Romero --- tests/tcg/aarch64/Makefile.target | 11 ++- tests/tcg/aarch64/gdbstub/test-mte.py | 86 ++ tests/tcg/aarch64/mte-8.c | 102 ++ 3 files changed, 197 insertions(+),

[PATCH 3/4] tests: Gently exit from GDB when tests complete

GDB commit a207f6b3a38 ('Rewrite "python" command exception handling') changed how exit() called from Python scripts loaded by GDB behave, turning it into an exception instead of a generic error code that is returned. This change caused several QEMU tests to crash with the following exception:

[PATCH 1/4] gdbstub: Add support for target-specific stubs

Currently, it's not possible to have stubs specific to a given target, even though there are GDB features which are target-specific, like, for instance, memory tagging. This commit introduces set_query_supported_arch, set_gdb_gen_query_table_arch, and set_gdb_gen_set_table_arch functions as

[PATCH 0/4] Add MTE stubs for aarch64 user mode

This patchset adds the stubs necessary to support GDB memory tagging commands on QEMU aarch64 user mode. These new stubs handle the qIsAddressTagged, qMemTag, and QMemTag packets, which allow GDB memory tagging subcommands 'check', 'print-allocation-tag', and 'set-allocation-tag' to work. The

Re: [PATCH 03/20] docs/qapidoc: delint a tiny portion of the module

John Snow writes: > On Wed, May 15, 2024 at 5:17 AM Markus Armbruster wrote: > >> John Snow writes: >> >> > In the coming patches, it's helpful to have a linting baseline. However, >> > there's no need to shuffle around the deck chairs too much, because most >> > of this code will be removed

Re: [PATCH v3 5/5] virtio-gpu: fix v2 migration

On Wed, May 15, 2024 at 11:03:27AM -0600, Peter Xu wrote: > On Wed, May 15, 2024 at 05:03:44PM +0100, Daniel P. Berrangé wrote: > > Above all, I'm failing to see why there's a compelling reason > > for virtio_gpu to diverge from our long standing practice of > > adding a named property flag

Re: [PATCH v11 08/10] virtio-gpu: Handle resource blob commands

On 5/15/24 20:04, Akihiko Odaki wrote: >> > > VIRTIO_GPU_CMD_RESOURCE_UNREF should also call > virtio_gpu_virgl_async_unmap_resource_blob(). I guess that's the > original intention of having a function for this instead of inlining the > content of this function to virgl_cmd_resource_unmap_blob().

Re: [PATCH v6 3/9] migration: Extend migration_file_set_error() with Error* argument

On 5/15/24 09:04, Eric Auger wrote: Hi Cédric, On 5/14/24 17:31, Cédric Le Goater wrote: Use it to update the current error of the migration stream if available and if not, simply print out the error. Next changes will update with an error to report. Reviewed-by: Avihai Horon Acked-by:

Re: [PATCH v6 2/9] vfio: Add Error** argument to vfio_devices_dma_logging_start()

On 5/15/24 08:53, Eric Auger wrote: Hi Cédric, On 5/14/24 17:31, Cédric Le Goater wrote: This allows to update the Error argument of the VFIO log_global_start() handler. Errors for container based logging will also be propagated to qemu_savevm_state_setup() when the ram save_setup() handler is

Re: [PATCH 1/2] hw/core: allow parameter=1 for SMP topology on any machine

On Tue, May 14, 2024 at 11:49:40AM +0800, Zhao Liu wrote: > > I'm failing to see what real world technical problems QEMU faces > > with a parameter being set to '1' by a mgmt app, when QEMU itself > > treats all omitted values as being '1' anyway. > > > > If we're trying to faithfully model the

Re: [PATCH 04/20] qapi/parser: preserve indentation in QAPIDoc sections

On Wed, May 15, 2024 at 10:18 AM Markus Armbruster wrote: > John Snow writes: > > > On Wed, May 15, 2024, 7:50 AM Markus Armbruster > wrote: > > > >> John Snow writes: > >> > >> > Prior to this patch, a section like this: > >> > > >> > @name: lorem ipsum > >> >dolor sit amet > >> >

Re: [PATCH v11 08/10] virtio-gpu: Handle resource blob commands

On 2024/05/16 2:01, Dmitry Osipenko wrote: On 5/15/24 19:42, Akihiko Odaki wrote: It may be better to actually implement unmapping instead of returning an error for consistency with the iov operation. Apparently crosvm also unmaps blobs with VIRTIO_GPU_CMD_RESOURCE_UNREF. Then I'll add back

Re: [PATCH v3 5/5] virtio-gpu: fix v2 migration

On Wed, May 15, 2024 at 05:03:44PM +0100, Daniel P. Berrangé wrote: > Above all, I'm failing to see why there's a compelling reason > for virtio_gpu to diverge from our long standing practice of > adding a named property flag "virtio_scanout_vmstate_fix" > on the machine class, and then setting it

Re: [PATCH 1/5] tcg: Introduce TCG_TARGET_HAS_tst_vec

On 15/5/24 16:58, Richard Henderson wrote: Prelude to supporting TCG_COND_TST* in vector comparisons. Signed-off-by: Richard Henderson --- include/tcg/tcg.h| 1 + tcg/aarch64/tcg-target.h | 1 + tcg/arm/tcg-target.h | 1 + tcg/i386/tcg-target.h| 1 +

Re: [PATCH v11 08/10] virtio-gpu: Handle resource blob commands

On 5/15/24 19:42, Akihiko Odaki wrote: >>> It may be better to actually implement unmapping instead of returning an >>> error for consistency with the iov operation. Apparently crosvm also >>> unmaps blobs with VIRTIO_GPU_CMD_RESOURCE_UNREF. >> >> Then I'll add back `async_unmap_in_progress`

Re: [PATCH v6 1/9] vfio: Add Error** argument to .set_dirty_page_tracking() handler

On 5/15/24 08:40, Eric Auger wrote: Hi Cédric, On 5/14/24 17:31, Cédric Le Goater wrote: We will use the Error object to improve error reporting in the .log_global*() handlers of VFIO. Add documentation while at it. Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Avihai Horon

Re: [PATCH 01/17] ppc64: Fix include order

On 15/5/24 15:53, Richard Henderson wrote: On 5/15/24 15:11, Philippe Mathieu-Daudé wrote: Hi Richard, On 11/5/24 13:53, Richard Henderson wrote: Signed-off-by: Richard Henderson ---   risu_ppc64.c | 3 +--   1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/risu_ppc64.c

Re: [PATCH v11 01/10] virtio-gpu: Unrealize GL device

On 5/15/24 19:22, Akihiko Odaki wrote: > On 2024/05/16 1:18, Dmitry Osipenko wrote: >> On 5/13/24 11:44, Akihiko Odaki wrote: >>> On 2024/05/12 3:22, Dmitry Osipenko wrote: Even though GL GPU doesn't support hotplugging today, free virgl resources when GL device is unrealized. For

Re: [PATCH v9] arm/kvm: Enable support for KVM_ARM_VCPU_PMU_V3_FILTER

On Mon, May 13, 2024 at 02:52:14PM +0800, Zhao Liu wrote: > Hi Daniel, > > > Please describe it in terms of a QAPI definition, as that's what we're > > striving for with all QEMU public interfaces. Once the QAPI design is > > agreed, then the -object mapping is trivial, as -object's JSON format >

Re: [PATCH v11 08/10] virtio-gpu: Handle resource blob commands

On 2024/05/16 1:39, Dmitry Osipenko wrote: On 5/13/24 12:18, Akihiko Odaki wrote:     static void virgl_cmd_resource_unref(VirtIOGPU *g, - struct virtio_gpu_ctrl_command *cmd) + struct virtio_gpu_ctrl_command *cmd, +   

Re: [PATCH v11 08/10] virtio-gpu: Handle resource blob commands

On 5/13/24 12:18, Akihiko Odaki wrote: >>     static void virgl_cmd_resource_unref(VirtIOGPU *g, >> - struct virtio_gpu_ctrl_command >> *cmd) >> + struct virtio_gpu_ctrl_command >> *cmd, >> +

Re: [PATCH v3 5/5] virtio-gpu: fix v2 migration

On Wed, May 15, 2024 at 12:02:49PM -0400, Michael S. Tsirkin wrote: > On Wed, May 15, 2024 at 06:15:56PM +0400, marcandre.lur...@redhat.com wrote: > > From: Marc-André Lureau > > > > Commit dfcf74fa ("virtio-gpu: fix scanout migration post-load") broke > > forward/backward version migration.

Re: [PATCH v2 03/11] vfio: Make VFIOIOMMUClass::attach_device() and its wrapper return bool

On 5/7/24 09:34, Duan, Zhenzhong wrote: -Original Message- From: Cédric Le Goater Subject: Re: [PATCH v2 03/11] vfio: Make VFIOIOMMUClass::attach_device() and its wrapper return bool On 5/7/24 08:42, Zhenzhong Duan wrote: Make VFIOIOMMUClass::attach_device() and its wrapper

Re: [PATCH v11 09/10] virtio-gpu: Register capsets dynamically

On 5/13/24 12:20, Akihiko Odaki wrote: ... >>   -int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g) >> +static void virtio_gpu_virgl_add_capset(GArray *capset_ids, uint32_t >> capset_id) >> +{ >> +    g_array_append_val(capset_ids, capset_id); >> +} > > Is it worthwhile to have a function for

Re: [PATCH v11 01/10] virtio-gpu: Unrealize GL device

On 2024/05/16 1:18, Dmitry Osipenko wrote: On 5/13/24 11:44, Akihiko Odaki wrote: On 2024/05/12 3:22, Dmitry Osipenko wrote: Even though GL GPU doesn't support hotplugging today, free virgl resources when GL device is unrealized. For consistency. Signed-off-by: Dmitry Osipenko ---  

Re: [PATCH v3 0/5] Fix "virtio-gpu: fix scanout migration post-load"

On Wed, May 15, 2024 at 10:07:31AM -0600, Peter Xu wrote: > On Wed, May 15, 2024 at 06:15:51PM +0400, marcandre.lur...@redhat.com wrote: > > From: Marc-André Lureau > > > > Hi, > > > > The aforementioned patch breaks virtio-gpu device migrations for versions > > pre-9.0/9.0, both forwards and

Re: [PATCH v3 2/4] vfio/migration: Emit VFIO migration QAPI event

On 5/15/24 15:21, Avihai Horon wrote: Emit VFIO migration QAPI event when a VFIO device changes its migration state. This can be used by management applications to get updates on the current state of the VFIO device for their own purposes. A new per VFIO device capability, "migration-events",

Re: [PATCH v11 01/10] virtio-gpu: Unrealize GL device

On 5/13/24 11:44, Akihiko Odaki wrote: > On 2024/05/12 3:22, Dmitry Osipenko wrote: >> Even though GL GPU doesn't support hotplugging today, free virgl >> resources when GL device is unrealized. For consistency. >> >> Signed-off-by: Dmitry Osipenko >> --- >>   hw/display/virtio-gpu-gl.c | 11

Re: [PATCH v3 4/4] vfio/migration: Enhance VFIO migration state tracing

On 5/15/24 15:21, Avihai Horon wrote: Move trace_vfio_migration_set_state() to the top of the function, add recover_state to it, and add a new trace event to vfio_migration_set_device_state(). This improves tracing of device state changes as state changes are now also logged when

Re: [PATCH 03/20] docs/qapidoc: delint a tiny portion of the module

On Wed, May 15, 2024 at 5:17 AM Markus Armbruster wrote: > John Snow writes: > > > In the coming patches, it's helpful to have a linting baseline. However, > > there's no need to shuffle around the deck chairs too much, because most > > of this code will be removed once the new qapidoc

Re: [PATCH v3 0/5] Fix "virtio-gpu: fix scanout migration post-load"

On Wed, May 15, 2024 at 06:15:51PM +0400, marcandre.lur...@redhat.com wrote: > From: Marc-André Lureau > > Hi, > > The aforementioned patch breaks virtio-gpu device migrations for versions > pre-9.0/9.0, both forwards and backwards. Versioning of `VMS_STRUCT` is more > complex than it may

Re: [PATCH v3 4/5] Set major/minor for PC and arm machines

On Wed, May 15, 2024 at 06:15:55PM +0400, marcandre.lur...@redhat.com wrote: > From: Marc-André Lureau > > Signed-off-by: Marc-André Lureau I would much rather compat machinery was in one place as opposed to being spread all over the codebase as this new API would encourage. > --- >

Re: [PATCH v3 5/5] virtio-gpu: fix v2 migration

On Wed, May 15, 2024 at 06:15:56PM +0400, marcandre.lur...@redhat.com wrote: > From: Marc-André Lureau > > Commit dfcf74fa ("virtio-gpu: fix scanout migration post-load") broke > forward/backward version migration. Versioning of nested VMSD structures > is not straightforward, as the wire format

Re: [PATCH v3 5/5] virtio-gpu: fix v2 migration

On Wed, May 15, 2024 at 06:15:56PM +0400, marcandre.lur...@redhat.com wrote: > From: Marc-André Lureau > > Commit dfcf74fa ("virtio-gpu: fix scanout migration post-load") broke > forward/backward version migration. Versioning of nested VMSD structures > is not straightforward, as the wire format

Re: [PATCH v3 2/2] vhost-user: fix lost reconnect again

The case your describing makes sense but now I have some concerns on the vhost_dev_cleanup bit. On Wed, May 15, 2024 at 1:47 AM Li Feng wrote: > > > > > 2024年5月14日 21:58，Raphael Norwitz 写道： > > > > Code looks good. Just a question on the error case you're trying to fix. > > > > On Tue, May 14,

Re: [PATCH v3 1/2] Revert "vhost-user: fix lost reconnect"

On Wed, May 15, 2024 at 1:47 AM Li Feng wrote: > > > > > 2024年5月14日 21:58，Raphael Norwitz 写道： > > > > The code for these two patches looks fine. Just some questions on the > > failure case you're trying to fix. > > > > > > On Tue, May 14, 2024 at 2:12 AM Li Feng wrote: > >> > >> This reverts

Re: [PATCH 00/41] target/sparc: Implement VIS4

On 4/29/24 23:02, Richard Henderson wrote: On 4/29/24 13:52, Mark Cave-Ayland wrote: No objections here about the remainder of the series, other than that I don't have an easy/obvious way to test the new instructions... I was thinking about adding support to RISU, but the gcc compile farm

[PATCH v3 11/28] target/i386: Convert do_xrstor_* to X86Access

The body of do_xrstor is now fully converted. Reviewed-by: Paolo Bonzini Signed-off-by: Richard Henderson --- target/i386/tcg/fpu_helper.c | 51 ++-- 1 file changed, 31 insertions(+), 20 deletions(-) diff --git a/target/i386/tcg/fpu_helper.c

[PATCH v3 14/28] target/i386: Add {hw, sw}_reserved to X86LegacyXSaveArea

This completes the 512 byte structure, allowing the union to be removed. Assert that the structure layout is as expected. Reviewed-by: Paolo Bonzini Signed-off-by: Richard Henderson --- target/i386/cpu.h | 39 +-- 1 file changed, 25 insertions(+), 14

[PATCH v3 04/28] target/i386: Convert do_fldenv to X86Access

Reviewed-by: Paolo Bonzini Signed-off-by: Richard Henderson --- target/i386/tcg/fpu_helper.c | 30 ++ 1 file changed, 14 insertions(+), 16 deletions(-) diff --git a/target/i386/tcg/fpu_helper.c b/target/i386/tcg/fpu_helper.c index 6237cd8383..5ad6e04639 100644 ---

[PATCH v3 26/28] target/i386: Pass host pointer and size to cpu_x86_{fsave, frstor}

We have already validated the memory region in the course of validating the signal frame. No need to do it again within the helper function. Reviewed-by: Paolo Bonzini Signed-off-by: Richard Henderson --- target/i386/cpu.h| 10 ++ linux-user/i386/signal.c | 4 ++--

[PATCH v3 01/28] target/i386: Add tcg/access.[ch]

Provide a method to amortize page lookup across large blocks. Reviewed-by: Paolo Bonzini Signed-off-by: Richard Henderson --- target/i386/tcg/access.h| 40 + target/i386/tcg/access.c| 169 target/i386/tcg/meson.build | 1 + 3 files

[PATCH v3 24/28] target/i386: Convert do_xsave to X86Access

Reviewed-by: Paolo Bonzini Signed-off-by: Richard Henderson --- linux-user/i386/signal.c | 2 +- target/i386/tcg/fpu_helper.c | 72 +--- 2 files changed, 43 insertions(+), 31 deletions(-) diff --git a/linux-user/i386/signal.c b/linux-user/i386/signal.c

[PATCH v3 28/28] target/i386: Pass host pointer and size to cpu_x86_{xsave, xrstor}

We have already validated the memory region in the course of validating the signal frame. No need to do it again within the helper function. In addition, return failure when the header contains invalid xstate_bv. The kernel handles this via exception handling within XSTATE_OP within

  1   2   3   4   >