[PATCH v4 02/18] vhost: Remove vhost_backend_can_merge() callback

Checking whether the memory regions are equal is sufficient: if they are equal, then most certainly the contained fd is equal. The whole vhost-user memslot handling is suboptimal and overly complicated. We shouldn't have to lookup a RAM memory regions we got notified about in vhost_user_get_mr_dat

[PATCH v4 03/18] softmmu/physmem: Fixup qemu_ram_block_from_host() documentation

Let's fixup the documentation (e.g., removing traces of the ram_addr parameter that no longer exists) and move it to the header file while at it. Suggested-by: Igor Mammedov Acked-by: Igor Mammedov Reviewed-by: Peter Xu Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: David Hildenbrand ---

[PATCH v4 09/18] memory-device, vhost: Support memory devices that dynamically consume memslots

We want to support memory devices that have a dynamically managed memory region container as device memory region. This device memory region maps multiple RAM memory subregions (e.g., aliases to the same RAM memory region), whereby these subregions can be (un)mapped on demand. Each RAM subregion w

[PATCH v4 07/18] stubs: Rename qmp_memory_device.c to memory_device.c

We want to place non-qmp stubs in there, so let's rename it. While at it, put it into the MAINTAINERS file under "Memory devices". Reviewed-by: Maciej S. Szmigiero Signed-off-by: David Hildenbrand --- MAINTAINERS| 1 + stubs/{qmp_memory_device.c => memory_dev

[PATCH v4 06/18] memory-device: Support memory devices with multiple memslots

We want to support memory devices that have a memory region container as device memory region that maps multiple RAM memory regions. Let's start by supporting memory devices that statically map multiple RAM memory regions and, thereby, consume multiple memslots. We already have one device that use

[PATCH v4 10/18] kvm: Add stub for kvm_get_max_memslots()

We'll need the stub soon from memory device context. While at it, use "unsigned int" as return value and place the declaration next to kvm_get_free_memslots(). Reviewed-by: Maciej S. Szmigiero Signed-off-by: David Hildenbrand --- accel/kvm/kvm-all.c| 2 +- accel/stubs/kvm-stub.c | 5 +

Re: [PATCH 02/12] hw/i386/intel_iommu: vtd_slpte_nonzero_rsvd(): reduce magic numbers

On Tue, 26 Sept 2023 at 19:36, Vladimir Sementsov-Ogievskiy wrote: > > On 26.09.23 13:37, Peter Maydell wrote: > > On Mon, 25 Sept 2023 at 20:41, Vladimir Sementsov-Ogievskiy > > wrote: > >> > >> Add a constant and clear assertion. The assertion also tells Coverity > >> that we are not going to o

[PATCH v4 18/18] virtio-mem: Mark memslot alias memory regions unmergeable

Let's mark the memslot alias memory regions as unmergable, such that flatview and vhost won't merge adjacent memory region aliases and we can atomically map/unmap individual aliases without affecting adjacent alias memory regions. This handles vhost and vfio in multiple-memslot mode correctly (whi

[PATCH v4 16/18] virtio-mem: Expose device memory dynamically via multiple memslots if enabled

Having large virtio-mem devices that only expose little memory to a VM is currently a problem: we map the whole sparse memory region into the guest using a single memslot, resulting in one gigantic memslot in KVM. KVM allocates metadata for the whole memslot, which can result in quite some memory w

[PATCH v4 12/18] memory-device, vhost: Support automatic decision on the number of memslots

We want to support memory devices that can automatically decide how many memslots they will use. In the worst case, they have to use a single memslot. The target use cases are virtio-mem and the hyper-v balloon. Let's calculate a reasonable limit such a memory device may use, and instruct the dev

[PATCH v4 14/18] virtio-mem: Pass non-const VirtIOMEM via virtio_mem_range_cb

Let's prepare for a user that has to modify the VirtIOMEM device state. Signed-off-by: David Hildenbrand --- hw/virtio/virtio-mem.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/hw/virtio/virtio-mem.c b/hw/virtio/virtio-mem.c index da5b09cefc..0b0e6c5090 100644 -

[PATCH v4 17/18] memory, vhost: Allow for marking memory device memory regions unmergeable

Let's allow for marking memory regions unmergeable, to teach flatview code and vhost to not merge adjacent aliases to the same memory region into a larger memory section; instead, we want separate aliases to stay separate such that we can atomically map/unmap aliases without affecting other aliases

[PATCH v4 11/18] vhost: Add vhost_get_max_memslots()

Let's add vhost_get_max_memslots(). Reviewed-by: Maciej S. Szmigiero Signed-off-by: David Hildenbrand --- hw/virtio/vhost-stub.c| 5 + hw/virtio/vhost.c | 11 +++ include/hw/virtio/vhost.h | 1 + 3 files changed, 17 insertions(+) diff --git a/hw/virtio/vhost-stub.c b/

[PATCH v4 13/18] memory: Clarify mapping requirements for RamDiscardManager

We really only care about the RAM memory region not being mapped into an address space yet as long as we're still setting up the RamDiscardManager. Once mapped into an address space, memory notifiers would get notified about such a region and any attempts to modify the RamDiscardManager would be wr

[PATCH v4 15/18] virtio-mem: Update state to match bitmap as soon as it's been migrated

It's cleaner and future-proof to just have other state that depends on the bitmap state to be updated as soon as possible when restoring the bitmap. So factor out informing RamDiscardListener into a functon and call it in case of early migration right after we restored the bitmap. Signed-off-by:

Re: [PATCH v3 4/4] migration/qapi: Drop @MigrationParameter enum

On Wed, Sep 06, 2023 at 11:46:16AM +0100, Daniel P. Berrangé wrote: > On Wed, Sep 06, 2023 at 12:14:54PM +0200, Philippe Mathieu-Daudé wrote: > > On 6/9/23 11:00, Daniel P. Berrangé wrote: > > > On Wed, Sep 06, 2023 at 06:42:16AM +0200, Philippe Mathieu-Daudé wrote: > > > > On 5/9/23 18:23, Peter X

Re: [PATCH v1 0/4] vfio: report NUMA nodes for device memory

On Tue, 26 Sep 2023 18:54:53 +0200 David Hildenbrand wrote: > On 26.09.23 16:52, Ankit Agrawal wrote: > > Good idea.  Fundamentally the device should not be creating NUMA > > nodes, the VM should be configured with NUMA nodes and the device > > memory associated with those nodes. >

Re: [PATCH 02/12] hw/i386/intel_iommu: vtd_slpte_nonzero_rsvd(): reduce magic numbers

On 26.09.23 21:59, Peter Maydell wrote: On Tue, 26 Sept 2023 at 19:36, Vladimir Sementsov-Ogievskiy wrote: On 26.09.23 13:37, Peter Maydell wrote: On Mon, 25 Sept 2023 at 20:41, Vladimir Sementsov-Ogievskiy wrote: Add a constant and clear assertion. The assertion also tells Coverity that w

Re: [Virtio-fs] [PATCH v3 0/5] vhost-user: Back-end state migration

On Tue, Sep 26, 2023, 09:33 Hanna Czenczek wrote: > On 25.09.23 22:48, Stefan Hajnoczi wrote: > > On Fri, Sep 15, 2023 at 12:25:25PM +0200, Hanna Czenczek wrote: > >> RFC: > >> https://lists.nongnu.org/archive/html/qemu-devel/2023-03/msg04263.html > >> > >> v1: > >> https://lists.nongnu.org/archi

[PATCH] optionrom: Remove build-id section

Our linker script for optionroms specifies only the placement of the .text section, leaving the linker free to place the remaining sections at arbitrary places in the file. Since at least binutils 2.39, the .note.gnu.build-id section is now being placed at the start of the file, which causes label

Re: [PATCH v3 2/5] vhost-user.rst: Clarify enabling/disabling vrings

On Tue, 26 Sept 2023 at 09:55, Hanna Czenczek wrote: > > On 25.09.23 21:15, Stefan Hajnoczi wrote: > > On Fri, Sep 15, 2023 at 12:25:27PM +0200, Hanna Czenczek wrote: > >> Currently, the vhost-user documentation says that rings are to be > >> initialized in a disabled state when VHOST_USER_F_PROTO

Re: [PATCH] mailmap: Fix Andrey Drobyshev author email

On Tue, Sep 26, 2023 at 02:46:44PM +0100, Peter Maydell wrote: > On Tue, 26 Sept 2023 at 14:40, Eric Blake wrote: > > > > On Tue, Sep 26, 2023 at 01:28:01PM +0300, andrey.drobys...@virtuozzo.com > > wrote: > > > From: Andrey Drobyshev > > > > > > This fixes authorship of commits 2848289168, 52b1

[PATCH 4/6] target/riscv/tcg: implement rva22u64 profile

The TCG emulation implements all the extensions described in the RVA22U64 profile, both mandatory and optional. The mandatory extensions will be enabled via the profile flag. We'll leave the optional extensions to be enabled by hand. Given that this is the first profile we're implementing in TCG w

[PATCH 3/6] target/riscv: add rva22u64 profile definition

The rva22U64 profile, described in: https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22-profiles Contains a set of CPU extensions aimed for 64-bit userspace applications. Enabling this set to be enabled via a single user flag makes it convenient to enable a predictable set of fe

[PATCH 1/6] target/riscv/cpu.c: add zicntr extension flag

zicntr is the Base Counters and Timers extension described in chapter 12 of the unprivileged spec. It describes support for RDCYCLE, RDTIME and RDINSTRET. QEMU already implements it way before it was a discrete extension. zicntr is part of the RVA22 profile, so let's add it to QEMU to make the fut

[PATCH 6/6] target/riscv/kvm: add 'rva22u64' flag as unavailable

KVM does not have the means to support enabling the rva22u64 profile. The main reasons are: - we're missing support for some mandatory rva22u64 extensions in the KVM module; - we can't make promises about enabling a profile since it all depends on host support in the end. We'll revisit this

[PATCH 2/6] target/riscv/cpu.c: add zihpm extension flag

zihpm is the Hardware Performance Counters extension described in chapter 12 of the unprivileged spec. It describes support for 29 unprivileged performance counters, hpmcounter3-hpmcounter21. As with zicntr, QEMU already implements zihpm before it was even an extension. zihpm is also part of the R

[PATCH 0/6] riscv: RVA22U64 profile support

Based-on: 20230926183109.165878-1-dbarb...@ventanamicro.com ("[PATCH 0/2] riscv: add extension properties for all cpus") Hi, These patches implements the base profile support for qemu-riscv and the first profile, RVA22U64. As discussed in this thread [1] we're aiming for a flag that enables all

[PATCH 5/6] target/riscv/tcg-cpu.c: enable profile support for vendor CPUs

Vendor CPUs can implement any profile they want as long as all required extensions are being set in their respective cpu_init(). We do not enable extensions for vendor CPUs and that will still be true with profile support. The idea then is to enable the profile option for vendor CPUs and let user

Re: [PATCH v2 12/12] vfio: Remove 64-bit IOVA address space assumption

Hi Alex, On 9/19/23 19:22, Alex Williamson wrote: > On Wed, 13 Sep 2023 10:01:47 +0200 > Eric Auger wrote: > >> Now we retrieve the usable IOVA ranges from the host, >> we now the physical IOMMU aperture and we can remove >> the assumption of 64b IOVA space when calling >> vfio_host_win_add(). >>

Re: [PATCH v3 0/4] qapi/migration: Dedup migration parameter objects and fix tls-authz crash

Peter Xu writes: > On Mon, Sep 25, 2023 at 02:59:30PM +0200, Markus Armbruster wrote: >> Peter, looks like you missed my review of v2. > > I definitely missed that if there is, but I didn't see any, and also > nothing I spot on the list, either.. > > https://lore.kernel.org/all/20230825171517.121

Re: [PATCH 1/1] block: improve alignment detection and fix 271 test

On 9/7/23 23:53, Denis V. Lunev wrote: Unfortunately 271 IO test is broken if started in non-cached mode. Commits commit a6b257a08e3d72219f03e461a52152672fec0612 Author: Nir Soffer Date: Tue Aug 13 21:21:03 2019 +0300 file-posix: Handle undetectable alignment and comm

Re: [Virtio-fs] [PATCH v3 0/5] vhost-user: Back-end state migration

Hi Hanna, I was thinking about how this could work without SUSPEND/RESUME. What do you think of the following? 1. The front-end sends VHOST_USER_RESET_DEVICE (or VHOST_USER_RESET_OWNER, when necessary) when the guest driver resets the device but not on vhost_dev_start()/vhost_dev_stop(). 2. Suspen

[PATCH v2 6/8] block/nvme: nvme_process_completion() fix bound for cid

NVMeQueuePair::reqs has length NVME_NUM_REQS, which less than NVME_QUEUE_SIZE by 1. Fixes: 1086e95da17050 ("block/nvme: switch to a NVMeRequest freelist") Signed-off-by: Vladimir Sementsov-Ogievskiy --- Cc: stefa...@redhat.com Cc: alex.c...@huawei.com Cc: euler.ro...@huawei.com Note, that there

[PATCH v2 3/8] libvhost-user.c: add assertion to vu_message_read_default

Explain Coverity that we are not going to overflow vmsg->fds. Signed-off-by: Vladimir Sementsov-Ogievskiy --- subprojects/libvhost-user/libvhost-user.c | 1 + 1 file changed, 1 insertion(+) diff --git a/subprojects/libvhost-user/libvhost-user.c b/subprojects/libvhost-user/libvhost-user.c index

[PATCH v2 8/8] io/channel-socket: qio_channel_socket_flush(): improve msg validation

For SO_EE_ORIGIN_ZEROCOPY the 32-bit notification range is encoded as [ee_info, ee_data] inclusively, so ee_info should be less or equal to ee_data. Signed-off-by: Vladimir Sementsov-Ogievskiy --- io/channel-socket.c | 5 + 1 file changed, 5 insertions(+) diff --git a/io/channel-socket.c b/

[PATCH v2 7/8] hw/core/loader: gunzip(): initialize z_stream

Coverity signals that variable as being used uninitialized. And really, when work with external APIs that's better to zero out the structure, where we set some fields by hand. Signed-off-by: Vladimir Sementsov-Ogievskiy --- hw/core/loader.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH v2 4/8] mc146818rtc: rtc_set_time(): initialize tm to zeroes

set_time() function doesn't set all the fields, so it's better to initialize tm structure. And Coverity will be happier about it. Signed-off-by: Vladimir Sementsov-Ogievskiy --- hw/rtc/mc146818rtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/rtc/mc146818rtc.c b/hw/rtc

[PATCH v2 1/8] hw/i386/intel_iommu: vtd_slpte_nonzero_rsvd(): assert no overflow

We support only 3- and 4-level page-tables, which is firstly checked in vtd_decide_config(), then setup in vtd_init(). Than level fields are checked by vtd_is_level_supported(). So here we can't have level out from 1..4 inclusive range. Let's assert it. That also explains Coverity that we are not

[PATCH v2 5/8] pcie_sriov: unregister_vfs(): fix error path

local_err must be NULL before calling object_property_set_bool(), so we must clear it on each iteration. Let's also use more convenient error_reportf_err(). Signed-off-by: Vladimir Sementsov-Ogievskiy --- hw/pci/pcie_sriov.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --

[PATCH v2 2/8] util/filemonitor-inotify: qemu_file_monitor_watch(): assert no overflow

Prefer clear assertions instead of [im]possible array overflow. Signed-off-by: Vladimir Sementsov-Ogievskiy --- util/filemonitor-inotify.c | 25 + 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/util/filemonitor-inotify.c b/util/filemonitor-inotify.c index

[PATCH v2 0/8] coverity fixes

v2: 01: add explanations, new assert and avoid extra assignment add CIDs [thx to Paolo] 02: add explanation, improve wording 04,07: s/{0}/{} 06,08: improve wording Hi! Here are some improvements to handle issues found by Coverity (not public Coverity site, so there are no CIDs). Vladimir Seme

Re: [PATCH] mailmap: Fix Andrey Drobyshev author email

On Tue, 26 Sept 2023 at 20:42, Eric Blake wrote: > > On Tue, Sep 26, 2023 at 02:46:44PM +0100, Peter Maydell wrote: > > On Tue, 26 Sept 2023 at 14:40, Eric Blake wrote: > > > > > > On Tue, Sep 26, 2023 at 01:28:01PM +0300, andrey.drobys...@virtuozzo.com > > > wrote: > > > > From: Andrey Drobyshe

Re: [PATCH v2 1/8] hw/i386/intel_iommu: vtd_slpte_nonzero_rsvd(): assert no overflow

On Tue, 26 Sept 2023 at 21:15, Vladimir Sementsov-Ogievskiy wrote: > > We support only 3- and 4-level page-tables, which is firstly checked in > vtd_decide_config(), then setup in vtd_init(). Than level fields are > checked by vtd_is_level_supported(). > > So here we can't have level out from 1..4

Re: [PATCH v2 2/8] util/filemonitor-inotify: qemu_file_monitor_watch(): assert no overflow

On Tue, 26 Sept 2023 at 21:15, Vladimir Sementsov-Ogievskiy wrote: > > Prefer clear assertions instead of [im]possible array overflow. > > Signed-off-by: Vladimir Sementsov-Ogievskiy > -- Reviewed-by: Peter Maydell thanks -- PMM

Re: [PATCH v2 4/8] mc146818rtc: rtc_set_time(): initialize tm to zeroes

On Tue, 26 Sept 2023 at 21:15, Vladimir Sementsov-Ogievskiy wrote: > > set_time() function doesn't set all the fields, so it's better to > initialize tm structure. And Coverity will be happier about it. > > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- > hw/rtc/mc146818rtc.c | 2 +- > 1 file

Re: [PATCH v2 7/8] hw/core/loader: gunzip(): initialize z_stream

On Tue, 26 Sept 2023 at 21:16, Vladimir Sementsov-Ogievskiy wrote: > > Coverity signals that variable as being used uninitialized. And really, > when work with external APIs that's better to zero out the structure, > where we set some fields by hand. > > Signed-off-by: Vladimir Sementsov-Ogievskiy

Re: [PATCH 1/2] i386/a-b-bootblock: factor test memory addresses out into constants

On 07.09.23 22:29, Daniil Tatianin wrote: So that we have less magic numbers to deal with. This also allows us to reuse these in the following commits. Signed-off-by: Daniil Tatianin Reviewed-by: Vladimir Sementsov-Ogievskiy -- Best regards, Vladimir

Re: [PATCH v2 41/58] i386/tdx: handle TDG.VP.VMCALL

I sent this reply to your question on the same day, but it got eaten by malfunctioning servers, and I noticed only now after another failure made me dig through my logs. Sorry for the inconvenience! Chenyi Qiang writes: > On 8/22/2023 4:24 PM, Daniel P. Berrangé wrote: >> On Tue, Aug 22, 2023 a

Re: [PATCH 2/2] i386/a-b-bootblock: zero the first byte of each page on start

On 07.09.23 22:29, Daniil Tatianin wrote: The migration qtest all the way up to this point used to work by sheer luck relying on the contents of all pages from 1MiB to 100MiB to contain the same one value in the first byte initially. This easily breaks if we reduce the amount of RAM for the test

Re: [PATCH v3 3/4] migration/qapi: Replace @MigrateSetParameters with @MigrationParameters

Peter Xu writes: > Quotting from Markus in his replies: Quoting Suggest something like "Markus recently wrote:" > migrate-set-parameters sets migration parameters, and > query-migrate-parameters gets them. Unsurprisingly, the former's > argument type MigrateSetParameters is quite close

[PATCH] maint: Tweak comment in mailmap to sound friendlier

From: Eric Blake Documenting that we should not add new lines to work around SPF rewrites sounds foreboding; the intent is instead that new lines here are okay, but indicate a second problem elsewhere in our build process that we should also consider fixing at the same time, to keep the section f

Re: [PATCH v2 6/8] block/nvme: nvme_process_completion() fix bound for cid

On Tue, Sep 26, 2023 at 11:15:30PM +0300, Vladimir Sementsov-Ogievskiy wrote: > NVMeQueuePair::reqs has length NVME_NUM_REQS, which less than > NVME_QUEUE_SIZE by 1. > > Fixes: 1086e95da17050 ("block/nvme: switch to a NVMeRequest freelist") > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- > >

Re: [PATCH v3 4/4] migration/qapi: Drop @MigrationParameter enum

Peter Xu writes: > Drop the enum in qapi because it is never used in QMP APIs. Instead making > it an internal definition for QEMU so that we can decouple it from QAPI, > and also we can deduplicate the QAPI documentations. > > Reviewed-by: Daniel P. Berrangé > Signed-off-by: Peter Xu The enu

Re: [PATCH v2 5/8] pcie_sriov: unregister_vfs(): fix error path

[add Markus] On 26.09.23 23:15, Vladimir Sementsov-Ogievskiy wrote: local_err must be NULL before calling object_property_set_bool(), so we must clear it on each iteration. Let's also use more convenient error_reportf_err(). Signed-off-by: Vladimir Sementsov-Ogievskiy --- hw/pci/pcie_sriov.c

Re: [v2] Help wanted for enabling -Wshadow=local

Warner Losh writes: > On Tue, Sep 26, 2023 at 8:43 AM Markus Armbruster wrote: > >> Brian, Gerd, Jason, Marc-André, Michael, we need your help to enable >> -Wshadow=local. >> >> Paolo, you already took care of several subsystems (thanks!), except you >> left a few warnings in target/i386/tcg/seg

Re: [PATCH 0/2] i386/a-b-bootblock: zero the first byte of each page on start

On Thu, Sep 07, 2023 at 10:29:42PM +0300, Daniil Tatianin wrote: > This series fixes an issue where the outcome of the migration qtest > relies on the initial memory contents all being the same across the > first 100MiB of RAM, which is a very fragile invariant. > > We fix this by making sure we z

Re: [PATCH 0/2] i386/a-b-bootblock: zero the first byte of each page on start

27.09.2023, 00:02, "Peter Xu" :On Thu, Sep 07, 2023 at 10:29:42PM +0300, Daniil Tatianin wrote: This series fixes an issue where the outcome of the migration qtest relies on the initial memory contents all being the same across the first 100MiB of RAM, which is a very fragile invariant.  We fix thi

Re: [PATCH 2/2] i386/a-b-bootblock: zero the first byte of each page on start

26.09.2023, 23:41, "Vladimir Sementsov-Ogievskiy" :On 07.09.23 22:29, Daniil Tatianin wrote: The migration qtest all the way up to this point used to work by sheer luck relying on the contents of all pages from 1MiB to 100MiB to contain the same one value in the first byte initially.  This easily b

Re: [PATCH 0/2] i386/a-b-bootblock: zero the first byte of each page on start

27.09.2023, 00:02, "Peter Xu" :On Thu, Sep 07, 2023 at 10:29:42PM +0300, Daniil Tatianin wrote: This series fixes an issue where the outcome of the migration qtest relies on the initial memory contents all being the same across the first 100MiB of RAM, which is a very fragile invariant.  We fix thi

Re: [PATCH v2 1/3] i386/a-b-bootblock: factor test memory addresses out into constants

On 19.09.23 13:23, Daniil Tatianin wrote: So that we have less magic numbers to deal with. This also allows us to reuse these in the following commits. Signed-off-by: Daniil Tatianin Reviewed-by: Peter Xu Reviewed-by: Vladimir Sementsov-Ogievskiy -- Best regards, Vladimir

Re: [PATCH v2 2/3] i386/a-b-bootblock: zero the first byte of each page on start

On 19.09.23 13:23, Daniil Tatianin wrote: The migration qtest all the way up to this point used to work by sheer luck relying on the contents of all pages from 1MiB to 100MiB to contain the same one value in the first byte initially. This easily breaks if we reduce the amount of RAM for the test

Re: [PATCH v2 3/3] s390x/a-b-bios: zero the first byte of each page on start

On 19.09.23 13:23, Daniil Tatianin wrote: Same as with the x86 verison of this test, we relied on the contents of all pages in RAM to be the same across the entire test range, which is very fragile. Zero the first byte of each page before running the increment loop to fix this. Fixes: 5571dc824b

Re: [PATCH v2 3/3] tests/qtest: Introduce tests for AMD/Xilinx Versal TRNG device

Hi Tong, On [2023 Sep 21] Thu 23:50:10, Tong Ho wrote: > Signed-off-by: Tong Ho > --- > tests/qtest/meson.build | 2 +- > tests/qtest/xlnx-versal-trng-test.c | 490 > 2 files changed, 491 insertions(+), 1 deletion(-) > create mode 100644 tests/qtest/xl

[PATCH RESEND v5 1/3] qmp: remove virtio_list, search QOM tree instead

The virtio_list duplicates information about virtio devices that already exist in the QOM composition tree. Instead of creating this list of realized virtio devices, search the QOM composition tree instead. This patch modifies the QMP command qmp_x_query_virtio to instead recursively search the QO

[PATCH RESEND v5 0/3] qmp, vhost-user: Remove virtio_list & update virtio introspection

These patches update a few things related to virtio introspection via. QMP/HMP commands. 1. Remove 'virtio_list' and instead query the QOM composition tree to find any active & realized virtio devices. The 'virtio_list' was duplicating information about virtio devices that was already available i

[PATCH RESEND v5 2/3] qmp: update virtio feature maps, vhost-user-gpio introspection

Add new vhost-user protocol feature to vhost-user protocol feature map and enumeration: - VHOST_USER_PROTOCOL_F_STATUS Add new virtio device features for several virtio devices to their respective feature mappings: virtio-blk: - VIRTIO_BLK_F_SECURE_ERASE virtio-net: - VIRTIO_NET_F_NOTF_COAL

[PATCH RESEND v5 3/3] vhost-user: move VhostUserProtocolFeature definition to header file

Move the definition of VhostUserProtocolFeature to include/hw/virtio/vhost-user.h. Remove previous definitions in hw/scsi/vhost-user-scsi.c, hw/virtio/vhost-user.c, and hw/virtio/virtio-qmp.c. Previously there were 3 separate definitions of this over 3 different files. Now only 1 definition of th

Re: [PATCH 1/2] hw/xen/xen_pt: Call default handler only if no custom one is set

On Tue, Nov 22, 2022 at 05:12:59PM +, Anthony PERARD wrote: > On Mon, Nov 14, 2022 at 08:20:10PM +0100, Marek Marczykowski-Górecki wrote: > > diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c > > index 0ec7e52183..269bd26109 100644 > > --- a/hw/xen/xen_pt.c > > +++ b/hw/xen/xen_pt.c > > @@ -255,6

Re: [PATCH RFC V2 01/37] arm/virt,target/arm: Add new ARMCPU {socket,cluster,core,thread}-id property

Hi Salil, On 9/26/23 20:04, Salil Mehta wrote: This shall be used to store user specified topology{socket,cluster,core,thread} and shall be converted to a unique 'vcpu-id' which is used as slot-index during hot(un)plug of vCPU. Note that we don't have 'vcpu-id' property. It's actually the ind

Re: [PATCH 50/52] migration/rdma: Silence qemu_rdma_cleanup()

On 26/09/2023 19:52, Markus Armbruster wrote: > "Zhijian Li (Fujitsu)" writes: > >> On 18/09/2023 22:42, Markus Armbruster wrote: >>> Functions that use an Error **errp parameter to return errors should >>> not also report them to the user, because reporting is the caller's >>> job. When the c

RE: [PATCH v1 04/22] vfio/common: Introduce vfio_container_add|del_section_window()

Hi Cédric, >-Original Message- >From: Duan, Zhenzhong >Sent: Thursday, September 21, 2023 6:14 PM >Subject: RE: [PATCH v1 04/22] vfio/common: Introduce >vfio_container_add|del_section_window() > >Hi Cédric, > >>-Original Message- >>From: Cédric Le Goater >>Sent: Thursday, Septembe

Re: [Qemu-devel] [PATCH 08/19] aspeed/timer: Fix behaviour running Linux

On Fri, 22 Sept 2023 at 13:21, Cédric Le Goater wrote: > > +t->start = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL); > > +return calculate_time(t, MAX(MAX(t->match[0], t->match[1]), 0)); > > This MAX(MAX(x, y), 0) looks strange to me. Would you remember where it comes > from ? Thanks, That look

Re: [PATCH v2 04/10] Introduce the CPU address space destruction function

Hi Salil Mehta: From: Salil Mehta Sent: Tuesday, September 26, 2023 12:21 PM To: 'David Hildenbrand' ; lixianglai ; qemu-devel@nongnu.org Cc: Salil Mehta ; Xiaojuan Yang ; Song Gao ; Michael S. Tsirkin ; Igor Mammedov ; Ani Sinha ; Paolo Bonzini ; Richard Henderson ; Eduardo Habkost ; Marcel Ap

Re: [PATCH v3 7/7] Update the ACPI table for the Loongarch CPU

Hi Salil Mehta: Hi Xianglai, From: xianglai li Sent: Tuesday, September 26, 2023 10:55 AM To: qemu-devel@nongnu.org Cc: Bernhard Beschow ; Salil Mehta ; Salil Mehta ; Xiaojuan Yang ; Song Gao ; Michael S. Tsirkin ; Igor Mammedov ; Ani Sinha ; Paolo Bonzini ; Richard Henderson ; Eduardo Habko

Re: [PATCH 1/4] aspeed/i2c: Clean up local variable shadowing

On Fri, 22 Sept 2023 at 15:59, Cédric Le Goater wrote: > > Remove superfluous local 'data' variable and use the one define at the > top of the routine. This fixes : > > ../hw/i2c/aspeed_i2c.c: In function ‘aspeed_i2c_bus_recv’: > ../hw/i2c/aspeed_i2c.c:315:17: warning: declaration of ‘data’ sh

Re: [PATCH RFC V2 02/37] cpus-common: Add common CPU utility for possible vCPUs

Hi Salil, On 9/26/23 20:04, Salil Mehta wrote: Adds various utility functions which might be required to fetch or check the state of the possible vCPUs. This also introduces concept of *disabled* vCPUs, which are part of the *possible* vCPUs but are not part of the *present* vCPU. This state sha

Re: [PATCH v5 00/28] bsd-user: Implement freebsd process related system calls.

On Mon, Sep 25, 2023 at 12:25 PM Karim Taha wrote: > > > Karim Taha (3): > bsd-user: define TARGET_RFSPAWN for rfork to use vfork(2) semantics, > and fix RLIM_INFINITY > bsd-user: Implement get_filename_from_fd. > bsd-user: Implement execve(2) and fexecve(2) system calls. > > Kyle Evans

Re: [PATCH v6 00/23] bsd-user: Implement mmap related system calls for FreeBSD.

On Mon, Sep 25, 2023 at 12:28 PM Karim Taha wrote: > Upstream the implementation of the following mmap system calls, from the > qemu-bsd-user fork: >mmap(2), munmap(2), >mprotect(2), >msync(2), >mlock(2), munlock(2), mlockall(2), munlockall(2), mincore(2), >madvise(2), >mi

Re: [PATCH 1/2] target/riscv: add riscv_cpu_get_name()

On Wed, Sep 27, 2023 at 5:35 AM Daniel Henrique Barboza wrote: > > We'll introduce generic errors that will output a CPU type name via its > RISCVCPU pointer. Create a helper for that. > > Use the helper in tcg_cpu_realizefn() instead of hardcoding the 'host' > CPU name. > > Signed-off-by: Daniel

Re: [PATCH] optionrom: Remove build-id section

On 26/09/2023 21.25, Fabiano Rosas wrote: Our linker script for optionroms specifies only the placement of the .text section, leaving the linker free to place the remaining sections at arbitrary places in the file. Since at least binutils 2.39, the .note.gnu.build-id section is now being placed

Re: [PATCH RFC V2 03/37] hw/arm/virt: Move setting of common CPU properties in a function

Hi Salil, On 9/26/23 20:04, Salil Mehta wrote: Factor out CPU properties code common for {hot,cold}-plugged CPUs. This allows code reuse. Signed-off-by: Salil Mehta --- hw/arm/virt.c | 220 ++ include/hw/arm/virt.h | 4 + 2 files changed, 1

Re: [PATCH 50/52] migration/rdma: Silence qemu_rdma_cleanup()

"Zhijian Li (Fujitsu)" writes: > On 26/09/2023 19:52, Markus Armbruster wrote: >> "Zhijian Li (Fujitsu)" writes: >> >>> On 18/09/2023 22:42, Markus Armbruster wrote: Functions that use an Error **errp parameter to return errors should not also report them to the user, because reportin

Re: [Qemu-devel] [PATCH 08/19] aspeed/timer: Fix behaviour running Linux

On 9/27/23 04:12, Joel Stanley wrote: On Fri, 22 Sept 2023 at 13:21, Cédric Le Goater wrote: +t->start = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL); +return calculate_time(t, MAX(MAX(t->match[0], t->match[1]), 0)); This MAX(MAX(x, y), 0) looks strange to me. Would you remember where it co

Re: [PATCH RESEND v5 2/3] qmp: update virtio feature maps, vhost-user-gpio introspection

On 26-09-23, 18:41, Jonah Palmer wrote: > Add new vhost-user protocol feature to vhost-user protocol feature map > and enumeration: > - VHOST_USER_PROTOCOL_F_STATUS > > Add new virtio device features for several virtio devices to their > respective feature mappings: > > virtio-blk: > - VIRTIO_B

Re: [PATCH RFC V2 04/37] arm/virt,target/arm: Machine init time change common to vCPU {cold|hot}-plug

Hi Salil, On 9/26/23 20:04, Salil Mehta wrote: Refactor and introduce the common logic required during the initialization of both cold and hot plugged vCPUs. Also initialize the *disabled* state of the vCPUs which shall be used further during init phases of various other components like GIC, PMU

Re: [PATCH RFC V2 04/37] arm/virt,target/arm: Machine init time change common to vCPU {cold|hot}-plug

On 9/26/23 20:04, Salil Mehta wrote: Refactor and introduce the common logic required during the initialization of both cold and hot plugged vCPUs. Also initialize the *disabled* state of the vCPUs which shall be used further during init phases of various other components like GIC, PMU, ACPI etc

Re: [Qemu-devel] [PATCH 08/19] aspeed/timer: Fix behaviour running Linux

Cédric Le Goater writes: > On 9/27/23 04:12, Joel Stanley wrote: >> On Fri, 22 Sept 2023 at 13:21, Cédric Le Goater wrote: >> +t->start = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL); +return calculate_time(t, MAX(MAX(t->match[0], t->match[1]), 0)); >>> >>> This MAX(MAX(x, y), 0) loo

Re: [PATCH v1 04/22] vfio/common: Introduce vfio_container_add|del_section_window()

On 9/27/23 04:08, Duan, Zhenzhong wrote: Hi Cédric, -Original Message- From: Duan, Zhenzhong Sent: Thursday, September 21, 2023 6:14 PM Subject: RE: [PATCH v1 04/22] vfio/common: Introduce vfio_container_add|del_section_window() Hi Cédric, -Original Message- From: Cédric Le G

Re: [PATCH RFC V2 05/37] accel/kvm: Extract common KVM vCPU {creation,parking} code

Hi Salil, On 9/26/23 20:04, Salil Mehta wrote: KVM vCPU creation is done once during the initialization of the VM when Qemu threads are spawned. This is common to all the architectures. If the architecture supports vCPU hot-{un}plug then this KVM vCPU creation could be deferred to later point a

Re: [PATCH] optionrom: Remove build-id section

Queued, thanks. Paolo

<    1   2   3   4