[PATCH 21/28] target/rx: Move has_work() from CPUClass to SysemuCPUOps

2025-01-21 Thread Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé --- target/rx/cpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/rx/cpu.c b/target/rx/cpu.c index aa310bd6144..79b95090e7a 100644 --- a/target/rx/cpu.c +++ b/target/rx/cpu.c @@ -187,6 +187,7 @@ static void rx_cpu_init(Object *obj

[PATCH 19/28] target/ppc: Move has_work() from CPUClass to SysemuCPUOps

2025-01-21 Thread Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé --- target/ppc/cpu_init.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/target/ppc/cpu_init.c b/target/ppc/cpu_init.c index c05c2dc42dc..081fb5bd343 100644 --- a/target/ppc/cpu_init.c +++ b/target/ppc/cpu_init.c @@ -7177,10 +7177,12 @

[PATCH 22/28] target/s390x: Restrict I/O handler installers to system emulation

2025-01-21 Thread Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé --- target/s390x/s390x-internal.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/target/s390x/s390x-internal.h b/target/s390x/s390x-internal.h index a750e7a343a..6e2c98de97a 100644 --- a/target/s390x/s390x-internal.h +++ b/target/s390x/s390x-internal.h

[PATCH 28/28] cpus: Remove CPUClass::has_work() handler

2025-01-21 Thread Philippe Mathieu-Daudé
All handlers have been converted to SysemuCPUOps::has_work(). Remove CPUClass::has_work along with cpu_common_has_work() and simplify cpu_has_work(), asserting SysemuCPUOps::has_work is always registered. Signed-off-by: Philippe Mathieu-Daudé --- include/hw/core/cpu.h | 2 -- hw/core/cpu-common.

[PATCH 13/28] target/i386: Move has_work() from CPUClass to SysemuCPUOps

2025-01-21 Thread Philippe Mathieu-Daudé
Move has_work() from CPUClass to SysemuCPUOps, restrict x86_cpu_pending_interrupt() to system. Signed-off-by: Philippe Mathieu-Daudé --- target/i386/cpu.h | 4 ++-- target/i386/cpu.c | 8 +++- 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/target/i386/cpu.h b/target/i386/cpu.

[PATCH 15/28] target/m68k: Move has_work() from CPUClass to SysemuCPUOps

2025-01-21 Thread Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé --- target/m68k/cpu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/target/m68k/cpu.c b/target/m68k/cpu.c index 41dfdf58045..eb7fb4f7e4c 100644 --- a/target/m68k/cpu.c +++ b/target/m68k/cpu.c @@ -51,10 +51,12 @@ static void m68k_resto

[PATCH 26/28] target/tricore: Move has_work() from CPUClass to SysemuCPUOps

2025-01-21 Thread Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé --- target/tricore/cpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/tricore/cpu.c b/target/tricore/cpu.c index 95202fadbfd..e4f95876efd 100644 --- a/target/tricore/cpu.c +++ b/target/tricore/cpu.c @@ -165,6 +165,7 @@ static boo

Re: [RFC v3 1/5] vhost-vdpa: Decouple the IOVA allocator

2025-01-21 Thread Jonah Palmer
On 1/16/25 11:44 AM, Eugenio Perez Martin wrote: On Fri, Jan 10, 2025 at 6:09 PM Jonah Palmer wrote: Decouples the IOVA allocator from the full IOVA->HVA tree to support a SVQ IOVA->HVA tree for host-only memory mappings. The IOVA allocator still allocates an IOVA range but instead adds th

[PATCH v2 1/2] memattrs: Convert unspecified member to bool

2025-01-21 Thread Zhao Liu
Convert `unspecified` member of MemTxAttrs from bit field to bool, so that bindgen could generate more ergonomic Rust binding with bool type. As a result, MemTxAttrs needs to be expanded from 4 bytes to 8 bytes. Therefore, move `unspecified` to after the bit fields and add reserved members to ens

[PATCH v2 2/2] memattrs: Check the size of MemTxAttrs

2025-01-21 Thread Zhao Liu
Make sure MemTxAttrs is packed into 8 bytes and does not exceed 8 bytes. Suggested-by: Philippe Mathieu-Daudà Signed-off-by: Zhao Liu --- Changes since v1: * Since MemTxAttrs has been well pakced as 8 bytes, only check if it exceed 8 bytes. --- include/exec/memattrs.h | 2 ++ 1 file changed

[PATCH v2 0/2] memattrs: miscellaneous cleanup to support memattrs binding

2025-01-21 Thread Zhao Liu
Hi, This is my v2. The link to v1 seems to be partially missing [1], and I've also double-checked previous comments from Peter, CLEMENT and Paolo to make sure I haven't lost everyone's feedback :-) (and because of yesterday's little mix-up, I also realized in time that I almost missed Paolo's feed

Re: [PATCH v7 4/4] qemu-options.hx: describe hub chardev and aggregation of several backends

2025-01-21 Thread Roman Penyaev
On Tue, Jan 21, 2025 at 4:02 PM Alex Bennée wrote: > > Roman Penyaev writes: > > > This adds a few lines describing `hub` aggregator configuration > > for aggregation of several backend devices with a single frontend > > device. > > > > Signed-off-by: Roman Penyaev > > Cc: "Marc-André Lureau" >

Re: [PATCH 2/3] hw/mem/cxl_type3: Fix special_ops memory leak on msix_init_exclusive_bar() failure

2025-01-21 Thread Jonathan Cameron via
On Tue, 21 Jan 2025 14:58:12 + Jonathan Cameron wrote: > On Mon, 20 Jan 2025 11:09:46 +0800 > Li Zhijian wrote: > > > Address a memory leak issue by ensuring `regs->special_ops` is freed when > > `msix_init_exclusive_bar()` encounters an error during CXL Type3 device > > initialization. > >

Re: [PATCH 2/7] guest_memfd: Introduce an object to manage the guest-memfd with RamDiscardManager

2025-01-21 Thread Peter Xu
On Tue, Jun 25, 2024 at 12:31:13AM +0800, Xu Yilun wrote: > On Mon, Jan 20, 2025 at 03:46:15PM -0500, Peter Xu wrote: > > On Mon, Jan 20, 2025 at 09:22:50PM +1100, Alexey Kardashevskiy wrote: > > > > It is still uncertain how to implement the private MMIO. Our assumption > > > > is the private MMIO

Re: [RFC v3 3/5] vhost-vdpa: Implement the GPA->IOVA tree

2025-01-21 Thread Jonah Palmer
On 1/16/25 2:00 PM, Eugenio Perez Martin wrote: On Fri, Jan 10, 2025 at 6:09 PM Jonah Palmer wrote: Implements the GPA->IOVA tree for handling mapping and unmapping for guest memory. This, alongside the SVQ IOVA->HVA tree & IOVA-only tree implemented in the previous patches, allows us to ha

[PATCH] stub: Fix build failure with --enable-user --disable-system --enable-tools

2025-01-21 Thread Zhao Liu
Configuring "--enable-user --disable-system --enable-tools" causes the build failure with the following information: /usr/bin/ld: libhwcore.a.p/hw_core_qdev.c.o: in function `device_finalize': /qemu/build/../hw/core/qdev.c:688: undefined reference to `qapi_event_send_device_deleted' collect2: err

Re: [PATCH v2 2/2] hw/ipack: Remove legacy qemu_allocate_irqs() use

2025-01-21 Thread Bernhard Beschow
Am 21. Januar 2025 10:04:43 UTC schrieb "Philippe Mathieu-Daudé" : >On 21/1/25 10:24, Bernhard Beschow wrote: >> >> >> Am 21. Januar 2025 08:44:52 UTC schrieb "Philippe Mathieu-Daudé" >> : >>> No need to dynamically allocate IRQ when we know before hands >>> how many we'll use. Declare the 2

Re: [PATCH] Skip resizing image to the same size

2025-01-21 Thread Fahrzin Hemmati
I'm running packer, and with a qcow2 source image sized at 75000MB (but only 5GB on disk) when it runs "qemu-img resize ... 75000MB" it takes about 10 seconds on my system. I guess it's not reading the whole disk since me nvme isn't that fast, but it's a non-trivial amount of work. It also runs a q

Re: [PATCH 0/3] Introduce CXL type-2 device emulation

2025-01-21 Thread Jonathan Cameron via
On Thu, 12 Dec 2024 18:10:10 + Zhi Wang wrote: > On 12/12/2024 18.49, Alejandro Lucero Palau wrote: > > > > On 12/12/24 13:04, Zhi Wang wrote: > >> Hi folks: > >> > >> Per the discussion with Ira/Jonathan in the LPC 2024 and in the CXL > >> discord channel, we are trying to introduce a CXL

Re: [PATCH] hw/virtio/vhost: Disable IOTLB callbacks when IOMMU gets disabled

2025-01-21 Thread Laurent Vivier
On 20/01/2025 18:33, Eric Auger wrote: When a guest exposed with a vhost device and protected by an intel IOMMU gets rebooted, we sometimes observe a spurious warning: Fail to lookup the translated address e000 We observe that the IOMMU gets disabled through a write to the global command re

Re: [PATCH 2/7] guest_memfd: Introduce an object to manage the guest-memfd with RamDiscardManager

2025-01-21 Thread Chenyi Qiang
Thanks Peter for your review! On 1/21/2025 2:09 AM, Peter Xu wrote: > Two trivial comments I spot: > > On Fri, Dec 13, 2024 at 03:08:44PM +0800, Chenyi Qiang wrote: >> +struct GuestMemfdManager { >> +Object parent; >> + >> +/* Managed memory region. */ >> +MemoryRegion *mr; >> + >> +

Re: [PATCH v17 00/16] TCG code quality tracking

2025-01-21 Thread Chinmay Rath
Hello Richard, Are you planning to come up with any new iterations of this patch series, or planning to merge it sometime ? This seems to be very useful, hence wanted to know your plans with this. Thanks, Chinmay On 11/14/24 14:58, Nikita Shubin wrote: Hello Richard and Vanderson ! Any news

Re: [PATCH 2/7] guest_memfd: Introduce an object to manage the guest-memfd with RamDiscardManager

2025-01-21 Thread David Hildenbrand
On 21.01.25 11:16, Chenyi Qiang wrote: On 1/21/2025 5:26 PM, David Hildenbrand wrote: On 21.01.25 10:00, Chenyi Qiang wrote: Thanks Peter for your review! On 1/21/2025 2:09 AM, Peter Xu wrote: Two trivial comments I spot: On Fri, Dec 13, 2024 at 03:08:44PM +0800, Chenyi Qiang wrote: +stru

Re: [PATCH 4/4] docs: Add GNR, SRF and CWF CPU models

2025-01-21 Thread Zhao Liu
On Tue, Jan 21, 2025 at 10:06:50AM +0800, Tao Su wrote: > Date: Tue, 21 Jan 2025 10:06:50 +0800 > From: Tao Su > Subject: [PATCH 4/4] docs: Add GNR, SRF and CWF CPU models > X-Mailer: git-send-email 2.34.1 > > Update GraniteRapids, SierraForest and ClearwaterForest CPU models in > section "Prefer

[PATCH v3 0/4] Allow to enable multifd and postcopy migration together

2025-01-21 Thread Prasad Pandit
From: Prasad Pandit Hello, * Currently Multifd and Postcopy migration can not be used together. QEMU shows "Postcopy is not yet compatible with multifd" message. When migrating guests with large (100's GB) RAM, Multifd threads help to accelerate migration, but inability to use it with the

Re: [PATCH] vfio: Support P2P access in confidential VM

2025-01-21 Thread David Hildenbrand
On 21.01.25 09:50, Wencheng Yang wrote: hi, David, Hi, > I'm wondering: isn't this something the kernel should be able to figure > out? Is this encrypted RAM (SMA) or not, and set the flag accordingly? > What are the challenges? VFIO driver and IOMMU driver don't know the device(memory o

Re: [PATCH 6/7] tests/qtest: tighten up the checks on clock_step

2025-01-21 Thread Peter Maydell
On Mon, 20 Jan 2025 at 21:02, Alex Bennée wrote: > > It is invalid to call clock_step with an implied time to step forward > as if no timers are running we won't be able to advance. > > Signed-off-by: Alex Bennée > --- > system/qtest.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-

[PATCH v3 2/4] migration: refactor ram_save_target_page functions

2025-01-21 Thread Prasad Pandit
From: Prasad Pandit Refactor ram_save_target_page legacy and multifd functions into one. Other than simplifying it, it frees 'migration_ops' object from usage, so it is expunged. Signed-off-by: Prasad Pandit --- migration/ram.c | 67 + 1 file cha

[PATCH v3 1/4] migration/multifd: move macros to multifd header

2025-01-21 Thread Prasad Pandit
From: Prasad Pandit Move MULTIFD_ macros to the header file so that they are accessible from other source files. Signed-off-by: Prasad Pandit --- migration/multifd.c | 5 - migration/multifd.h | 5 + 2 files changed, 5 insertions(+), 5 deletions(-) v2: - https://lore.kernel.org/qemu-

Re: [RFC PATCH] tests/qtest: don't step clock at start of npcm7xx periodic IRQ test

2025-01-21 Thread Peter Maydell
On Mon, 20 Jan 2025 at 23:52, Hao Wu wrote: > > Have you tried that the test can pass with this? If I remember correctly, > interrupt won't trigger properly if not advancing the timer > > If the test passes it's probably fine to remove that. This specific clock_step_next() call is done immediate

Re: [PATCH 2/7] guest_memfd: Introduce an object to manage the guest-memfd with RamDiscardManager

2025-01-21 Thread Chenyi Qiang
On 1/21/2025 5:26 PM, David Hildenbrand wrote: > On 21.01.25 10:00, Chenyi Qiang wrote: >> Thanks Peter for your review! >> >> On 1/21/2025 2:09 AM, Peter Xu wrote: >>> Two trivial comments I spot: >>> >>> On Fri, Dec 13, 2024 at 03:08:44PM +0800, Chenyi Qiang wrote: +struct GuestMemfdManag

Re: [PATCH v2 2/2] hw/ipack: Remove legacy qemu_allocate_irqs() use

2025-01-21 Thread Philippe Mathieu-Daudé
On 21/1/25 10:24, Bernhard Beschow wrote: Am 21. Januar 2025 08:44:52 UTC schrieb "Philippe Mathieu-Daudé" : No need to dynamically allocate IRQ when we know before hands how many we'll use. Declare the 2 of them in IPackDevice state and initialize them in the DeviceRealize handler. Signed-o

[PATCH v3 4/4] tests/qtest/migration: add postcopy test with multifd

2025-01-21 Thread Prasad Pandit
From: Prasad Pandit Add a new postcopy test 'migration/postcopy/multifd' to run postcopy migration with multifd channels enabled. Add a boolean field 'multifd' to the MigrateCommon struct. It helps to enable multifd channels. Signed-off-by: Prasad Pandit --- tests/qtest/migration/framework.c

[PATCH v3 3/4] migration: enable multifd and postcopy together

2025-01-21 Thread Prasad Pandit
From: Prasad Pandit Enable Multifd and Postcopy migration together. The migration_ioc_process_incoming() routine checks magic value sent on each channel and helps to properly setup multifd and postcopy channels. The Precopy and Multifd threads work during the initial guest RAM transfer. When mig

Re: [PATCH 2/7] guest_memfd: Introduce an object to manage the guest-memfd with RamDiscardManager

2025-01-21 Thread David Hildenbrand
On 21.01.25 10:00, Chenyi Qiang wrote: Thanks Peter for your review! On 1/21/2025 2:09 AM, Peter Xu wrote: Two trivial comments I spot: On Fri, Dec 13, 2024 at 03:08:44PM +0800, Chenyi Qiang wrote: +struct GuestMemfdManager { +Object parent; + +/* Managed memory region. */ +Memory

Re: [RFC PATCH] tests/qtest: don't step clock at start of npcm7xx periodic IRQ test

2025-01-21 Thread Alex Bennée
Hao Wu writes: > Have you tried that the test can pass with this? If I remember correctly, > interrupt won't trigger properly if not advancing the > timer Yes but the IRQ has yet to be enabled at this point. > > If the test passes it's probably fine to remove that. Of course. > > On Mon, Jan

Re: [PATCH 03/13] linux-user: Emulate /proc/cpuinfo for Alpha

2025-01-21 Thread Philippe Mathieu-Daudé
Hi Helge, On 24/8/23 03:02, Richard Henderson wrote: From: Helge Deller Add emulation for /proc/cpuinfo for the alpha architecture. alpha output example: (alpha-chroot)root@p100:/# cat /proc/cpuinfo cpu : Alpha cpu model : ev67 cpu variation : 0 cp

Re: [PATCH v3 2/3] hw/sd/sdhci: Introduce a new Write Protected pin inverted property

2025-01-21 Thread Cédric Le Goater
Jamin, +Bernhard On 11/14/24 10:48, Jamin Lin wrote: The Write Protect pin of SDHCI model is default active low to match the SDHCI spec. So, write enable the bit 19 should be 1 and write protected the bit 19 should be 0 at the Present State Register (0x24). However, some boards are design Write

Re: [PATCH v3] hw/i386/cpu: remove default_cpu_version and simplify

2025-01-21 Thread Zhao Liu
Hi Ani, Sorry for late reply. On Thu, Jan 16, 2025 at 09:04:18AM +0530, Ani Sinha wrote: > Date: Thu, 16 Jan 2025 09:04:18 +0530 > From: Ani Sinha > Subject: [PATCH v3] hw/i386/cpu: remove default_cpu_version and simplify > X-Mailer: git-send-email 2.45.2 > > commit 0788a56bd1ae3 ("i386: Make u

Re: [PATCH] mips: Mark the "mipssim" machine as deprecated

2025-01-21 Thread Philippe Mathieu-Daudé
On 21/1/25 11:36, Thomas Huth wrote: We are not aware of anybody still using this machine, support for it has been withdrawn from the Linux kernel (i.e. there also won't be any future development anymore), and we are not aware of any binaries online that could be used for regression testing to av

Re: [PATCH 1/2] hw/ipack: Clarify KConfig symbols

2025-01-21 Thread Fabiano Rosas
Philippe Mathieu-Daudé writes: > Split IPACK Kconfig key as {IPACK, TPCI200, IP_OCTAL_232} > > - IPack is a bus > - TPCI200 is a PCI device providing an IPack bus > - IP-Octal232 is an IPack device plugged on an IPack bus > > Signed-off-by: Philippe Mathieu-Daudé Acked-by: Fabiano Rosas

[PATCH RESEND] i386: Only configure HPET firmware info when HPET is enabled

2025-01-21 Thread Zhao Liu
At present, the hpet_cfg is written unconditionally since 40ac17cd56eb ("pass info about hpets to seabios.]"), because it concerns ACPI HPET is created unconditionally. But that fact has changed since 51124bbfd2ea ("i386: acpi: Don't build HPET ACPI entry if HPET is disabled") and ACPI checks if H

Re: [PATCH 0/4] Introduce SierraForest-v2 and ClearwaterForest CPU model

2025-01-21 Thread Paolo Bonzini
Queued with the tweaks suggested by Zoltan and Zhao; thanks! Paolo

[PATCH RESEND 0/2] rust/pl011: miscellaneous cleanups

2025-01-21 Thread Zhao Liu
(Resend the series since it was missed on https://lore.kernel.org/qemu-devel/.) Hi, This series includes the following cleanups: * Patch 1: Make realize() safe to only accept immutable self reference, which is in prepare to introduce gpio bindings [1]. * Patch 2: Clean

[PATCH RESEND 2/2] rust/pl011: Avoid bindings::*

2025-01-21 Thread Zhao Liu
List all the necessary bindings to better identify gaps in rust/qapi. And include the bindings wrapped by rust/qapi instead mapping the raw bindings directly. Inspired-by: Paolo Bonzini Signed-off-by: Zhao Liu --- rust/hw/char/pl011/src/device.rs | 13 ++--- 1 file changed, 10 insertion

[PATCH RESEND 1/2] rust/qdev: Make REALIZE safe

2025-01-21 Thread Zhao Liu
A safe REALIZE accepts immutable reference. Since current PL011's realize() only calls a char binding function ( qemu_chr_fe_set_handlers), it is possible to convert mutable reference (&mut self) to immutable reference (&self), which only needs to convert the pointers passed to C to mutable pointe

Re: [PATCH 0/7] testing/next (qtest timer stuff)

2025-01-21 Thread Fabiano Rosas
Alex Bennée writes: > Hi, > > Thomas found that a number of tests fail under CFI and other exotic > setups. The eventual realisation was that --enable-slirp masks a lot > of timer misuse because it ensures there is always a timer and > therefor things tend to move on (until the system is shutting

[PATCH 06/11] gdbstub: Prefer cached CpuClass over CPU_GET_CLASS() macro

2025-01-21 Thread Philippe Mathieu-Daudé
CpuState caches its CPUClass since commit 6fbdff87062 ("cpu: cache CPUClass in CPUState for hot code paths"), use it. Signed-off-by: Philippe Mathieu-Daudé --- gdbstub/gdbstub.c | 26 +- gdbstub/system.c | 7 ++- gdbstub/user-target.c | 6 ++ gdbstub/us

[PATCH 11/11] target/openrisc: Prefer cached CpuClass over CPU_GET_CLASS() macro

2025-01-21 Thread Philippe Mathieu-Daudé
CpuState caches its CPUClass since commit 6fbdff87062 ("cpu: cache CPUClass in CPUState for hot code paths"), use it. Signed-off-by: Philippe Mathieu-Daudé --- target/openrisc/gdbstub.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/target/openrisc/gdbstub.c b/target/openr

[PATCH 02/11] cpus: Prefer cached CpuClass over CPU_GET_CLASS() macro

2025-01-21 Thread Philippe Mathieu-Daudé
CpuState caches its CPUClass since commit 6fbdff87062 ("cpu: cache CPUClass in CPUState for hot code paths"), use it. Signed-off-by: Philippe Mathieu-Daudé --- include/hw/core/cpu.h | 10 +++- cpu-common.c | 10 cpu-target.c | 6 ++--- hw/core/cpu-common.c | 13 +

Re: [PATCH v3 4/4] overcommit: introduce mem-lock=on-fault

2025-01-21 Thread Daniil Tatianin
On 1/9/25 5:18 PM, Peter Xu wrote: On Thu, Jan 09, 2025 at 11:47:40AM +0300, Daniil Tatianin wrote: On 12/12/24 7:20 PM, Peter Xu wrote: On Thu, Dec 12, 2024 at 02:04:33AM +0300, Daniil Tatianin wrote: Locking the memory without MCL_ONFAULT instantly prefaults any mmaped anonymous memory wit

[PATCH 01/11] cpus: Cache CPUClass early in instance_init() handler

2025-01-21 Thread Philippe Mathieu-Daudé
Cache CPUClass as early as possible, when the instance is initialized. Signed-off-by: Philippe Mathieu-Daudé --- cpu-target.c | 3 --- hw/core/cpu-common.c | 3 +++ 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/cpu-target.c b/cpu-target.c index 667688332c9..89874496a41 1

[PATCH 10/11] target/microblaze: Prefer cached CpuClass over CPU_GET_CLASS() macro

2025-01-21 Thread Philippe Mathieu-Daudé
CpuState caches its CPUClass since commit 6fbdff87062 ("cpu: cache CPUClass in CPUState for hot code paths"), use it. Signed-off-by: Philippe Mathieu-Daudé --- target/microblaze/gdbstub.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/target/microblaze/gdbstub.c b/target/m

Re: [PATCH] Skip resizing image to the same size

2025-01-21 Thread Kevin Wolf
Am 20.01.2025 um 23:21 hat Fahrzin Hemmati geschrieben: > Happy to wait until your patchset is in. > > Yes, this is a no-op, but it reads the entire disk image to perform that > no-op, so this is merely a time-saving improvement, not a behavior change. Can you give more context on what exactly yo

[PATCH 00/11] cpus: Prefer cached CpuClass over CPU_GET_CLASS() macro

2025-01-21 Thread Philippe Mathieu-Daudé
Use cached CPUState::cc to get CPUClass. Main rationale is overall code style. Philippe Mathieu-Daudé (11): cpus: Cache CPUClass early in instance_init() handler cpus: Prefer cached CpuClass over CPU_GET_CLASS() macro accel: Prefer cached CpuClass over CPU_GET_CLASS() macro user: Prefer ca

[PATCH 03/11] accel: Prefer cached CpuClass over CPU_GET_CLASS() macro

2025-01-21 Thread Philippe Mathieu-Daudé
CpuState caches its CPUClass since commit 6fbdff87062 ("cpu: cache CPUClass in CPUState for hot code paths"), use it. Signed-off-by: Philippe Mathieu-Daudé --- accel/accel-target.c | 12 +--- accel/tcg/tcg-accel-ops.c | 3 +-- accel/tcg/translate-all.c | 2 +- accel/tcg/watchpoint

[PATCH 07/11] hw/acpi: Prefer cached CpuClass over CPU_GET_CLASS() macro

2025-01-21 Thread Philippe Mathieu-Daudé
CpuState caches its CPUClass since commit 6fbdff87062 ("cpu: cache CPUClass in CPUState for hot code paths"), use it. Signed-off-by: Philippe Mathieu-Daudé --- hw/acpi/cpu.c | 4 ++-- hw/acpi/cpu_hotplug.c | 3 +-- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/hw/acpi/cp

[PATCH 08/11] hw/core/generic-loader: Prefer cached CpuClass over CPU_GET_CLASS macro

2025-01-21 Thread Philippe Mathieu-Daudé
CpuState caches its CPUClass since commit 6fbdff87062 ("cpu: cache CPUClass in CPUState for hot code paths"), use it. Signed-off-by: Philippe Mathieu-Daudé --- hw/core/generic-loader.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/hw/core/generic-loader.c b/hw/core/gene

[PATCH 09/11] target/arm: Prefer cached CpuClass over CPU_GET_CLASS() macro

2025-01-21 Thread Philippe Mathieu-Daudé
CpuState caches its CPUClass since commit 6fbdff87062 ("cpu: cache CPUClass in CPUState for hot code paths"), use it. Signed-off-by: Philippe Mathieu-Daudé --- target/arm/cpu.c | 3 +-- target/arm/tcg/cpu-v7m.c | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/targe

[PATCH 05/11] disas: Prefer cached CpuClass over CPU_GET_CLASS() macro

2025-01-21 Thread Philippe Mathieu-Daudé
CpuState caches its CPUClass since commit 6fbdff87062 ("cpu: cache CPUClass in CPUState for hot code paths"), use it. Signed-off-by: Philippe Mathieu-Daudé --- disas/disas-common.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/disas/disas-common.c b/disas/disas-common.

[PATCH 04/11] user: Prefer cached CpuClass over CPU_GET_CLASS() macro

2025-01-21 Thread Philippe Mathieu-Daudé
CpuState caches its CPUClass since commit 6fbdff87062 ("cpu: cache CPUClass in CPUState for hot code paths"), use it. Signed-off-by: Philippe Mathieu-Daudé --- linux-user/alpha/target_proc.h | 2 +- bsd-user/signal.c | 4 ++-- linux-user/signal.c| 4 ++-- 3 files changed

Re: [PATCH 0/7] testing/next (qtest timer stuff)

2025-01-21 Thread Thomas Huth
On 20/01/2025 22.02, Alex Bennée wrote: Hi, Thomas found that a number of tests fail under CFI and other exotic setups. The eventual realisation was that --enable-slirp masks a lot of timer misuse because it ensures there is always a timer and therefor things tend to move on (until the system is

Re: [PATCH 3/7] tests/qtest: don't step clock at start of npcm7xx periodic IRQ test

2025-01-21 Thread Thomas Huth
On 20/01/2025 22.02, Alex Bennée wrote: Until there are timers enabled the semantics of clock_step_next() will fail. Since d524441a36 (system/qtest: properly feedback results of clock_[step|set]) we will signal a FAIL if time doesn't advance. Signed-off-by: Alex Bennée --- tests/qtest/npcm7xx

Re: [PATCH 3/4] target/i386: Add new CPU model ClearwaterForest

2025-01-21 Thread Zhao Liu
On Tue, Jan 21, 2025 at 10:06:49AM +0800, Tao Su wrote: > Date: Tue, 21 Jan 2025 10:06:49 +0800 > From: Tao Su > Subject: [PATCH 3/4] target/i386: Add new CPU model ClearwaterForest > X-Mailer: git-send-email 2.34.1 > > According to table 1-2 in Intel Architecture Instruction Set Extensions > and

Re: [PATCH 2/3] hw/mem/cxl_type3: Fix special_ops memory leak on msix_init_exclusive_bar() failure

2025-01-21 Thread Jonathan Cameron via
On Mon, 20 Jan 2025 11:09:46 +0800 Li Zhijian wrote: > Address a memory leak issue by ensuring `regs->special_ops` is freed when > `msix_init_exclusive_bar()` encounters an error during CXL Type3 device > initialization. > > Additionally, this patch renames err_address_space_free to err_msix_uni

Re: [RFC v3 2/5] vhost-iova-tree: Remove range check for IOVA allocator

2025-01-21 Thread Jonah Palmer
On 1/16/25 12:02 PM, Eugenio Perez Martin wrote: On Fri, Jan 10, 2025 at 6:09 PM Jonah Palmer wrote: Removes the range check portion in vhost_iova_tree_map_alloc. The previous patch decoupled the IOVA allocator from adding mappings to the IOVA->HVA tree (now a partial SVQ IOVA->HVA tree) a

Re: [PATCH 3/3] hw/mem/cxl_type3: Ensure errp is set on realization failure

2025-01-21 Thread Jonathan Cameron via
On Mon, 20 Jan 2025 11:09:47 +0800 Li Zhijian wrote: > Simply pass the errp to its callee which will set errp if needed, to > enhance error reporting for CXL Type 3 device initialization by setting > the errp when realization functions fail. > > Previously, failing to set `errp` could result in

Re: [PATCH v7 4/4] qemu-options.hx: describe hub chardev and aggregation of several backends

2025-01-21 Thread Alex Bennée
Roman Penyaev writes: > This adds a few lines describing `hub` aggregator configuration > for aggregation of several backend devices with a single frontend > device. > > Signed-off-by: Roman Penyaev > Cc: "Marc-André Lureau" > Cc: qemu-devel@nongnu.org > --- > qemu-options.hx | 48

Re: [PATCH v2] gdbstub/user-target: fix gdbserver int format (%d -> %x)

2025-01-21 Thread Michael Tokarev
21.01.2025 01:28, Dominik 'Disconnect3d' Czarnota wrote: This commit fixes an incorrect format string for formatting integers provided to GDB when debugging a target run in QEMU user mode. The correct format is hexadecimal for both success and errno values, some of which can be seen here [0]. [

[PATCH 00/28] cpus: Restrict CPU has_work() handlers to system emulation

2025-01-21 Thread Philippe Mathieu-Daudé
On user emulation, threads always have work to do, and CPUClass::has_work() is never called. Restrict it to system emulation, allowing to simplify a bit and reduce code built on user emulation. Based-on: <20250121114056.53949-1-phi...@linaro.org> "cpus: Prefer cached CpuClass over CPU_GET_CLASS()

[PATCH 14/28] target/loongarch: Move has_work() from CPUClass to SysemuCPUOps

2025-01-21 Thread Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé --- target/loongarch/cpu.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/target/loongarch/cpu.c b/target/loongarch/cpu.c index d611a604704..20aba0e1fff 100644 --- a/target/loongarch/cpu.c +++ b/target/loongarch/cpu.c @@ -349,11 +

[PATCH 08/28] target/alpha: Move has_work() from CPUClass to SysemuCPUOps

2025-01-21 Thread Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé --- target/alpha/cpu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/target/alpha/cpu.c b/target/alpha/cpu.c index e1b898e5755..83164a694d8 100644 --- a/target/alpha/cpu.c +++ b/target/alpha/cpu.c @@ -63,6 +63,7 @@ static void alpha_r

[PATCH 01/28] target/hexagon: Ensure not being build on system emulation

2025-01-21 Thread Philippe Mathieu-Daudé
Currently only user emulation is supported. Assert no target code is built for system emulation. Signed-off-by: Philippe Mathieu-Daudé --- target/hexagon/cpu.h | 4 1 file changed, 4 insertions(+) diff --git a/target/hexagon/cpu.h b/target/hexagon/cpu.h index 79e60d4bfa1..f78c8f9c2a0 10064

[PATCH 12/28] target/hppa: Move has_work() from CPUClass to SysemuCPUOps

2025-01-21 Thread Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé --- target/hppa/cpu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/target/hppa/cpu.c b/target/hppa/cpu.c index b0bc9d35e4c..d5a58a03cbb 100644 --- a/target/hppa/cpu.c +++ b/target/hppa/cpu.c @@ -125,10 +125,12 @@ static void hppa_res

[PATCH 18/28] target/openrisc: Move has_work() from CPUClass to SysemuCPUOps

2025-01-21 Thread Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé --- target/openrisc/cpu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/target/openrisc/cpu.c b/target/openrisc/cpu.c index b7bab0d7abf..5d80c4aa9ac 100644 --- a/target/openrisc/cpu.c +++ b/target/openrisc/cpu.c @@ -63,11 +63,13 @@ st

[PATCH 16/28] target/microblaze: Move has_work() from CPUClass to SysemuCPUOps

2025-01-21 Thread Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé --- target/microblaze/cpu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/target/microblaze/cpu.c b/target/microblaze/cpu.c index f114789abd8..7a90cb3016b 100644 --- a/target/microblaze/cpu.c +++ b/target/microblaze/cpu.c @@ -115,10 +

[PATCH 05/28] cpus: Restrict cpu_has_work() to system emulation

2025-01-21 Thread Philippe Mathieu-Daudé
This method is not used on user emulation, because there is always work to do there. Signed-off-by: Philippe Mathieu-Daudé --- include/hw/core/cpu.h | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h in

[PATCH 02/28] target/rx: Ensure not being build on user emulation

2025-01-21 Thread Philippe Mathieu-Daudé
Currently only system emulation is supported. Assert no target code is built for user emulation. Remove #ifdef'ry since more work is required before being able to emulate a user process. Signed-off-by: Philippe Mathieu-Daudé --- target/rx/cpu.h| 6 -- target/rx/cpu.c| 6 -- targe

[PATCH 07/28] cpus: Introduce SysemuCPUOps::has_work() handler

2025-01-21 Thread Philippe Mathieu-Daudé
SysemuCPUOps::has_work() is similar to CPUClass::has_work(), but only exposed on system emulation. Signed-off-by: Philippe Mathieu-Daudé --- include/hw/core/sysemu-cpu-ops.h | 4 hw/core/cpu-system.c | 4 2 files changed, 8 insertions(+) diff --git a/include/hw/core/sysemu

[PATCH 09/28] target/arm: Move has_work() from CPUClass to SysemuCPUOps

2025-01-21 Thread Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé --- target/arm/cpu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/target/arm/cpu.c b/target/arm/cpu.c index 048b825a006..322c95038d5 100644 --- a/target/arm/cpu.c +++ b/target/arm/cpu.c @@ -123,6 +123,7 @@ void arm_restore_state_to_o

[PATCH 03/28] target/tricore: Ensure not being build on user emulation

2025-01-21 Thread Philippe Mathieu-Daudé
Currently only system emulation is supported. Assert no target code is built for user emulation. Signed-off-by: Philippe Mathieu-Daudé --- target/tricore/cpu.h | 4 1 file changed, 4 insertions(+) diff --git a/target/tricore/cpu.h b/target/tricore/cpu.h index 8e431d79222..cf9dbc6df8e 10064

[PATCH 10/28] target/avr: Move has_work() from CPUClass to SysemuCPUOps

2025-01-21 Thread Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé --- target/avr/cpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/avr/cpu.c b/target/avr/cpu.c index 8a126ff3222..8712813f3e2 100644 --- a/target/avr/cpu.c +++ b/target/avr/cpu.c @@ -200,6 +200,7 @@ static void avr_cpu_dump_state

[PATCH 23/28] target/s390x: Move has_work() from CPUClass to SysemuCPUOps

2025-01-21 Thread Philippe Mathieu-Daudé
Move has_work() from CPUClass to SysemuCPUOps, move s390_cpu_has_work() to cpu-system.c so it is only build for system emulation binaries, restrict functions not used anymore on user emulation in interrupt.c. Signed-off-by: Philippe Mathieu-Daudé --- target/s390x/s390x-internal.h | 3 +++ targe

[PATCH 27/28] target/xtensa: Move has_work() from CPUClass to SysemuCPUOps

2025-01-21 Thread Philippe Mathieu-Daudé
Move has_work() from CPUClass to SysemuCPUOps, simplifying xtensa_cpu_has_work() by directly using CPU env. Signed-off-by: Philippe Mathieu-Daudé --- target/xtensa/cpu.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/target/xtensa/cpu.c b/target/xtensa/cpu.c ind

[PATCH 17/28] target/mips: Move has_work() from CPUClass to SysemuCPUOps

2025-01-21 Thread Philippe Mathieu-Daudé
Move has_work() from CPUClass to SysemuCPUOps and cpu_mips_hw_interrupts_enabled() to system. Signed-off-by: Philippe Mathieu-Daudé --- target/mips/internal.h | 4 ++-- target/mips/cpu.c | 4 +++- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/target/mips/internal.h b/target

[PATCH 11/28] target/hexagon: Remove CPUClass:has_work() handler

2025-01-21 Thread Philippe Mathieu-Daudé
Remove as unreachable code. Signed-off-by: Philippe Mathieu-Daudé --- target/hexagon/cpu.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/target/hexagon/cpu.c b/target/hexagon/cpu.c index 0b7fc98f6ce..f77e305d611 100644 --- a/target/hexagon/cpu.c +++ b/target/hexagon/cpu.c @@ -262,11 +

[PATCH 04/28] cpus: Restrict cpu_get_memory_mapping() to system emulation

2025-01-21 Thread Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé --- include/hw/core/cpu.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h index b7367f6d808..2402706c7d9 100644 --- a/include/hw/core/cpu.h +++ b/include/hw/core/cpu.h @@ -614,6 +614,8 @@ e

[PATCH 06/28] cpus: Un-inline cpu_has_work()

2025-01-21 Thread Philippe Mathieu-Daudé
In order to expand cpu_has_work(), un-inline it. Signed-off-by: Philippe Mathieu-Daudé --- include/hw/core/cpu.h | 6 +- hw/core/cpu-system.c | 6 ++ 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h index e094d54949d..d64c823e7

[PATCH 25/28] target/sparc: Move has_work() from CPUClass to SysemuCPUOps

2025-01-21 Thread Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé --- target/sparc/cpu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/target/sparc/cpu.c b/target/sparc/cpu.c index fbd38ec334a..94e807f9f84 100644 --- a/target/sparc/cpu.c +++ b/target/sparc/cpu.c @@ -776,11 +776,13 @@ static void spa

[PATCH 20/28] target/riscv: Move has_work() from CPUClass to SysemuCPUOps

2025-01-21 Thread Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé --- target/riscv/cpu.h | 9 + target/riscv/internals.h | 3 --- target/riscv/cpu.c | 8 +++- 3 files changed, 8 insertions(+), 12 deletions(-) diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h index 97713681cbe..32e8e064f36 100644

[PATCH 24/28] target/sh4: Move has_work() from CPUClass to SysemuCPUOps

2025-01-21 Thread Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé --- target/sh4/cpu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/sh4/cpu.c b/target/sh4/cpu.c index 24a22724c61..80a66e1f1d6 100644 --- a/target/sh4/cpu.c +++ b/target/sh4/cpu.c @@ -82,12 +82,12 @@ static bool superh_io_reco

Re: [PATCH v7 1/4] chardev/char-pty: send CHR_EVENT_CLOSED on disconnect

2025-01-21 Thread Alex Bennée
Roman Penyaev writes: > Change makes code symmetric to the code, which handles > the "connected" state, i.e. send CHR_EVENT_CLOSED when > state changes from "connected" to "disconnected". > > This behavior is similar to char-socket, for example. > > Signed-off-by: Roman Penyaev > Cc: "Marc-André

Re: [RFC v3 5/5] svq: Support translations via GPAs in vhost_svq_translate_addr

2025-01-21 Thread Jonah Palmer
On 1/16/25 2:29 PM, Eugenio Perez Martin wrote: On Fri, Jan 10, 2025 at 6:09 PM Jonah Palmer wrote: Propagates the GPAs (in_xlat_addr/out_xlat_addr) of a VirtQueueElement to vhost_svq_translate_addr() to translate to IOVAs via GPA->IOVA tree when descriptors are backed by guest memory. For

Re: [PATCH 2/7] guest_memfd: Introduce an object to manage the guest-memfd with RamDiscardManager

2025-01-21 Thread Peter Xu
On Tue, Jan 21, 2025 at 05:00:45PM +0800, Chenyi Qiang wrote: > >> + > >> +/* block size and alignment */ > >> +uint64_t block_size; > > > > Can we always fetch it from the MR/ramblock? If this is needed, better add > > some comment explaining why. > > The block_size is the granularity us

Re: [PATCH v3 4/4] tests/qtest/migration: add postcopy test with multifd

2025-01-21 Thread Peter Xu
On Tue, Jan 21, 2025 at 06:40:32PM +0530, Prasad Pandit wrote: > From: Prasad Pandit > > Add a new postcopy test 'migration/postcopy/multifd' > to run postcopy migration with multifd channels enabled. > Add a boolean field 'multifd' to the MigrateCommon struct. > It helps to enable multifd channe

Re: [PATCH v2 2/2] target/riscv: throw debug exception before page fault

2025-01-21 Thread Richard Henderson
On 1/20/25 12:49, Daniel Henrique Barboza wrote: In the RISC-V privileged ISA section 3.1.15 table 15, it is determined that a debug exception that is triggered from a load/store has a higher priority than a possible fault that this access might trigger. This is not the case ATM as shown in [1].

[PATCH 2/2] hw/ipack: Remove legacy qemu_allocate_irqs() use

2025-01-21 Thread Philippe Mathieu-Daudé
No need to dynamically allocate IRQ when we know before hands how many we'll use. Declare the 2 of them in IPackDevice state and initialize them in the DeviceRealize handler. Signed-off-by: Philippe Mathieu-Daudé --- include/hw/ipack/ipack.h | 7 ++- hw/ipack/ipack.c | 7 +++ 2 f

Re: [PATCH 6/7] RAMBlock: make guest_memfd require coordinate discard

2025-01-21 Thread David Hildenbrand
On 21.01.25 07:26, Chenyi Qiang wrote: On 1/20/2025 9:11 PM, David Hildenbrand wrote: On 14.01.25 02:38, Chenyi Qiang wrote: On 1/13/2025 6:56 PM, David Hildenbrand wrote: On 13.12.24 08:08, Chenyi Qiang wrote: As guest_memfd is now managed by guest_memfd_manager with RamDiscardManager, o

Re: [PATCH] vfio: Support P2P access in confidential VM

2025-01-21 Thread Wencheng Yang
hi, David, > I'm wondering: isn't this something the kernel should be able to figure > out? Is this encrypted RAM (SMA) or not, and set the flag accordingly? > What are the challenges? VFIO driver and IOMMU driver don't know the device(memory or device mmio) behind vaddr, only device driver knows

Re: [PATCH] hw/virtio/vhost: Disable IOTLB callbacks when IOMMU gets disabled

2025-01-21 Thread Stefano Garzarella
On Tue, Jan 21, 2025 at 09:31:53AM +0100, Laurent Vivier wrote: On 20/01/2025 18:33, Eric Auger wrote: When a guest exposed with a vhost device and protected by an intel IOMMU gets rebooted, we sometimes observe a spurious warning: Fail to lookup the translated address e000 We observe that

  1   2   3   >