Re: [PATCH 2/4] target/i386: nvmm, whpx: add accel/CPU class that sets host vendor

On 7/11/2025 2:35 PM, Paolo Bonzini wrote: Il ven 11 lug 2025, 04:18 Xiaoyao Li ha scritto: Besides, do we need to call host_cpu_max_instance_init() for the case of xcc->max_features, like what has been done for kvm and hvf? I am intentionally skipping that because it would not have any eff

Re: [PATCH 4/4] target/i386: move accel_cpu_instance_init to .instance_init

Il ven 11 lug 2025, 04:26 Xiaoyao Li ha scritto: > BTW, the user's value of "pmu" and "invtsc" are still broken for TDX > case. tdx_cpu_instance_init() will always overwrite "pmu" and "invtsc" > even if users explicitly request a different value via "-cpu" option. > > Will we leave it as intenti

Re: [PATCH 2/4] target/i386: nvmm, whpx: add accel/CPU class that sets host vendor

Il ven 11 lug 2025, 04:18 Xiaoyao Li ha scritto: > Besides, do we need to call host_cpu_max_instance_init() for the case of > xcc->max_features, like what has been done for kvm and hvf? > I am intentionally skipping that because it would not have any effect and there is no equivalent to KVM_GET_

Re: [PATCH v6 1/1] hw/display: Allow injection of virtio-gpu EDID name

On Wed, Jul 9, 2025 at 4:11 PM Andrew Keesler wrote: > > Thanks to 72d277a7, 1ed2cb32, and others, EDID (Extended Display > Identification Data) is propagated by QEMU such that a virtual display > presents legitimate metadata (e.g., name, serial number, preferred > resolutions, etc.) to its connec

Re: [PATCH 4/4] target/i386: move accel_cpu_instance_init to .instance_init

On Fri, Jul 11, 2025 at 02:06:03AM +0200, Paolo Bonzini wrote: > Date: Fri, 11 Jul 2025 02:06:03 +0200 > From: Paolo Bonzini > Subject: [PATCH 4/4] target/i386: move accel_cpu_instance_init to > .instance_init > X-Mailer: git-send-email 2.50.0 > > With the reordering of instance_post_init callba

Re: [PATCH v9 02/16] backends/confidential-guest-support: Add functions to support IGVM

On Tue, Jul 8, 2025 at 8:37 PM Daniel P. Berrangé wrote: > > On Thu, Jul 03, 2025 at 04:03:10PM +0100, Roy Hopkins wrote: > > In preparation for supporting the processing of IGVM files to configure > > guests, this adds a set of functions to ConfidentialGuestSupport > > allowing configuration of s

Re: [PATCH 3/4] target/i386: allow reordering max_x86_cpu_initfn vs accel CPU init

On Fri, Jul 11, 2025 at 02:06:02AM +0200, Paolo Bonzini wrote: > Date: Fri, 11 Jul 2025 02:06:02 +0200 > From: Paolo Bonzini > Subject: [PATCH 3/4] target/i386: allow reordering max_x86_cpu_initfn vs > accel CPU init > X-Mailer: git-send-email 2.50.0 > > The PMU feature is only supported by KVM,

[PATCH v2 16/18] qapi: add cross-references to virtio.json

Signed-off-by: John Snow --- qapi/virtio.json | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/qapi/virtio.json b/qapi/virtio.json index d1556dbf24a..3bc8700e943 100644 --- a/qapi/virtio.json +++ b/qapi/virtio.json @@ -135,7 +135,7 @@ # @num-vqs: VirtIODevice virtqueue

[PATCH v2 12/18] qapi: add cross-references to replay.json

Signed-off-by: John Snow --- qapi/replay.json | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/qapi/replay.json b/qapi/replay.json index 35e0c4a6926..78244a9d0bf 100644 --- a/qapi/replay.json +++ b/qapi/replay.json @@ -47,8 +47,8 @@ # @query-replay: # # Retrieve t

[PATCH v2 17/18] qapi: add cross-references to yank.json

Signed-off-by: John Snow Acked-by: Lukas Straub --- qapi/yank.json | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/qapi/yank.json b/qapi/yank.json index 5f26d6c0149..f1b737e87d6 100644 --- a/qapi/yank.json +++ b/qapi/yank.json @@ -9,7 +9,7 @@ ## # @YankInst

[PATCH v2 04/18] qapi: add cross-references to crypto.json

Signed-off-by: John Snow --- qapi/crypto.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/qapi/crypto.json b/qapi/crypto.json index 9ec6301e188..57620d95da6 100644 --- a/qapi/crypto.json +++ b/qapi/crypto.json @@ -589,9 +589,9 @@ # # Specific parameters for RSA algor

[PATCH v2 15/18] qapi: add cross-references to ui.json

Signed-off-by: John Snow --- qapi/ui.json | 34 +- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/qapi/ui.json b/qapi/ui.json index 7136c985c38..5bc54403cc2 100644 --- a/qapi/ui.json +++ b/qapi/ui.json @@ -39,7 +39,7 @@ ## # @SetPasswordOptions:

[PATCH v2 09/18] qapi: add cross-references to net.json

Signed-off-by: John Snow --- qapi/net.json | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/qapi/net.json b/qapi/net.json index 371ade0dc6a..8631c8dd61c 100644 --- a/qapi/net.json +++ b/qapi/net.json @@ -655,7 +655,7 @@ # this to zero disables this function. This me

[PATCH v2 11/18] qapi: add cross-references to QOM

Signed-off-by: John Snow --- qapi/qdev.json | 4 ++-- qapi/qom.json | 13 +++-- 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/qapi/qdev.json b/qapi/qdev.json index 5d18fb8e0e0..ff3f06a36d6 100644 --- a/qapi/qdev.json +++ b/qapi/qdev.json @@ -95,10 +95,10 @@ #from t

[PATCH v2 03/18] qapi: add cross-references to block layer

Signed-off-by: John Snow --- qapi/block-core.json | 188 - qapi/block-export.json | 36 qapi/block.json| 14 +-- qapi/transaction.json | 12 +-- 4 files changed, 125 insertions(+), 125 deletions(-) diff --git a/qapi/block-core.json b

[PATCH v2 18/18] qapi: add cross-references to misc modules

These modules don't have specific maintainers, so they're lumped in together here as miscellaneous. Signed-off-by: John Snow --- qapi/control.json| 2 +- qapi/ebpf.json | 2 +- qapi/introspect.json | 24 qapi/misc-arm.json | 4 ++-- qapi/misc-i386.json |

[PATCH v2 10/18] qapi: add cross-references to pci.json

Signed-off-by: John Snow --- qapi/pci.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/qapi/pci.json b/qapi/pci.json index 29549d94551..4aad5f98e2a 100644 --- a/qapi/pci.json +++ b/qapi/pci.json @@ -83,7 +83,7 @@ # # @bus: information about the bus the device resides on

[PATCH v2 06/18] qapi: add cross-references to job.json

Signed-off-by: John Snow --- qapi/job.json | 71 ++- 1 file changed, 36 insertions(+), 35 deletions(-) diff --git a/qapi/job.json b/qapi/job.json index c1ddae9c0fe..a6026f6a810 100644 --- a/qapi/job.json +++ b/qapi/job.json @@ -10,26 +10,26 @@ #

[PATCH v2 13/18] qapi: add cross-references to run-state.json

Signed-off-by: John Snow --- qapi/run-state.json | 46 ++--- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/qapi/run-state.json b/qapi/run-state.json index 759f8730059..bafbbf695b2 100644 --- a/qapi/run-state.json +++ b/qapi/run-state.json

[PATCH v2 08/18] qapi: add cross-references to migration.json

Signed-off-by: John Snow --- qapi/migration.json | 68 ++--- 1 file changed, 34 insertions(+), 34 deletions(-) diff --git a/qapi/migration.json b/qapi/migration.json index 59a213aeb6c..eda27c18102 100644 --- a/qapi/migration.json +++ b/qapi/migration.json

[PATCH v2 14/18] qapi: add cross-references to sockets.json

Signed-off-by: John Snow Reviewed-by: Eric Blake --- qapi/sockets.json | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/qapi/sockets.json b/qapi/sockets.json index f9f559dabae..e7f8b42bda3 100644 --- a/qapi/sockets.json +++ b/qapi/sockets.json @@ -209,14 +209,14 @@

[PATCH v2 00/18] QAPI: add cross-references to qapi docs

Based-on: 20250711051045.51110-1-js...@redhat.com [PATCH v6 0/4] qapi: add auto-generated return docs v2: - Applied a few new transformations I had missed. - Manually excluded those Markus pointed out as being unhelpful. Hi, this patch series is a *mostly* mechanical application of QAPI cro

[PATCH v2 07/18] qapi: add cross-references to Machine core

Signed-off-by: John Snow --- qapi/machine-common.json | 20 +- qapi/machine.json| 82 2 files changed, 51 insertions(+), 51 deletions(-) diff --git a/qapi/machine-common.json b/qapi/machine-common.json index 298e51f373a..a9f56cbbb43 100644

[PATCH v2 05/18] qapi: add cross-references to dump.json

Signed-off-by: John Snow --- qapi/dump.json | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/qapi/dump.json b/qapi/dump.json index 3a9b67efb1b..a615e73a64a 100644 --- a/qapi/dump.json +++ b/qapi/dump.json @@ -110,7 +110,7 @@ # # Describe the status of a long-runn

[PATCH v2 02/18] qapi: add cross-references to authz.json

Signed-off-by: John Snow --- qapi/authz.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/qapi/authz.json b/qapi/authz.json index 7fc6e3032ea..cbd9399c461 100644 --- a/qapi/authz.json +++ b/qapi/authz.json @@ -75,7 +75,7 @@ # Properties for authz-listfile objects. # # @f

[PATCH v2 01/18] qapi: add cross-references to acpi.json

Signed-off-by: John Snow --- qapi/acpi.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/qapi/acpi.json b/qapi/acpi.json index 2d53b823656..8e48d8874dd 100644 --- a/qapi/acpi.json +++ b/qapi/acpi.json @@ -106,7 +106,7 @@ ## # @query-acpi-ospm-status: # -# Return a list o

Re: [PATCH 08/18] qapi: add cross-references to migration.json

On Wed, Jul 2, 2025 at 4:04 AM Markus Armbruster wrote: > > John Snow writes: > > > Signed-off-by: John Snow > > --- > > qapi/migration.json | 62 ++--- > > 1 file changed, 31 insertions(+), 31 deletions(-) > > > > diff --git a/qapi/migration.json b/qapi/

Re: [PATCH 2/4] target/i386: nvmm, whpx: add accel/CPU class that sets host vendor

On Fri, Jul 11, 2025 at 02:06:01AM +0200, Paolo Bonzini wrote: > Date: Fri, 11 Jul 2025 02:06:01 +0200 > From: Paolo Bonzini > Subject: [PATCH 2/4] target/i386: nvmm, whpx: add accel/CPU class that sets > host vendor > X-Mailer: git-send-email 2.50.0 > > NVMM and WHPX are virtualizers, and there

[PATCH v6 2/4] docs, qapi: generate undocumented return sections

This patch changes the qapidoc parser to generate stub Return value documentation for any command that has a return value but does not have a "Returns:" doc section. The stubs include just the type name, which will be rendered with a cross-reference link in the HTML output. The algorithm for wher

[PATCH v6 1/4] docs/qapi-domain: add return-nodesc

This form is used to annotate a return type without an accompanying description, for when there is no "Returns:" information in the source doc, but we have a return type we want to generate a cross-reference to. The syntax is: :return-nodesc: TypeName It's primarily necessary because Sphinx alwa

[PATCH v6 4/4] qapi: rephrase return docs to avoid type name

Well, I tried. Maybe not very hard. Sorry! Signed-off-by: John Snow --- qapi/block-core.json | 6 +++--- qapi/block-export.json | 2 +- qapi/block.json| 2 +- qapi/control.json | 5 ++--- qapi/dump.json | 5 ++--- qapi/introspect.json | 6 +++--- qapi/job.json |

[PATCH v6 0/4] qapi: add auto-generated return docs

This series adds the ability for the new QAPIDoc system to generate "Returns:" documentation based on the return type declared in the Schema even when no explicit documentation is found in the QAPI source. As a result and as an immediate cleanup, trivial return statements are removed and remaining

[PATCH v6 3/4] qapi: remove trivial "Returns:" sections

The new qapidoc.py can generate "Returns" statements with type information just fine, so we can remove it from the source where it doesn't add anything particularly novel or helpful and just repeats the type info. This patch is fairly "gentle" and doesn't aggressively touch other "Returns" lines t

RE: [PATCH] i386/tdx: Use .has_gpa field to check if the gpa is valid

>-Original Message- >From: Li, Xiaoyao >Subject: [PATCH] i386/tdx: Use .has_gpa field to check if the gpa is valid > >There is actually the .has_gpa field when translating the QAPI data >type GuestPanicInformationTdx to C structure. > >Stop using the magic number -1 as the indicator for

Re: [PATCH 1/4] target/i386: move max_features to class

On Fri, Jul 11, 2025 at 02:06:00AM +0200, Paolo Bonzini wrote: > Date: Fri, 11 Jul 2025 02:06:00 +0200 > From: Paolo Bonzini > Subject: [PATCH 1/4] target/i386: move max_features to class > X-Mailer: git-send-email 2.50.0 > > max_features is always set to true for instances created by -cpu max or

Re: [PATCH 4/4] target/i386: move accel_cpu_instance_init to .instance_init

On 7/11/2025 8:06 AM, Paolo Bonzini wrote: With the reordering of instance_post_init callbacks that is new in 10.1 accel_cpu_instance_init must execute in .instance_init as is already the case for RISC-V. Otherwise, for example, setting the vendor property is broken when using KVM or Hypervisor.

Re: [PATCH 3/4] target/i386: allow reordering max_x86_cpu_initfn vs accel CPU init

On 7/11/2025 8:06 AM, Paolo Bonzini wrote: The PMU feature is only supported by KVM, so move it there. And since all accelerators other than TCG overwrite the vendor, set it in max_x86_cpu_initfn only if it has not been initialized by the superclass. This makes it possible to run max_x86_cpu_in

Re: [PATCH 2/4] target/i386: nvmm, whpx: add accel/CPU class that sets host vendor

On 7/11/2025 8:06 AM, Paolo Bonzini wrote: NVMM and WHPX are virtualizers, and therefore they need to use (at least by default) the host vendor for the guest CPUID. Add a cpu_instance_init implementation to these accelerators. Signed-off-by: Paolo Bonzini --- target/i386/cpu.c | 8

[PATCH] qga: Fix truncated output handling in guest-exec status reporting

From: "minglei.liu" Signed-off-by: minglei.liu --- qga/commands.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/qga/commands.c b/qga/commands.c index 5a5fad31f8..5f20af25d3 100644 --- a/qga/commands.c +++ b/qga/commands.c @@ -205,13 +205,15 @@ GuestExecStatus *qmp_gu

Re: [PATCH 2/4] target/i386: nvmm, whpx: add accel/CPU class that sets host vendor

On 7/11/2025 8:06 AM, Paolo Bonzini wrote: NVMM and WHPX are virtualizers, and therefore they need to use (at least by default) the host vendor for the guest CPUID. Add a cpu_instance_init implementation to these accelerators. Signed-off-by: Paolo Bonzini --- target/i386/cpu.c | 8

Re: [PATCH v4 02/11] hw/loongarch: add virt feature avecintc support

在 2025/7/10 上午9:54, Bibo Mao 写道: @@ -1238,6 +1262,12 @@ static void virt_class_init(ObjectClass *oc, const void *data)   NULL, NULL);   object_class_property_set_description(oc, "v-eiointc",   "Enable Virt Extend I/O Interrupt Controller."); +#ifdef CONF

[PATCH 1/2] docs/system: arm: Add max78000 board description

This adds the target guide for the max78000FTHR Signed-off-by: Jackson Donaldson --- docs/system/arm/max78000.rst | 35 +++ 1 file changed, 35 insertions(+) create mode 100644 docs/system/arm/max78000.rst diff --git a/docs/system/arm/max78000.rst b/docs/system/a

[PATCH 0/2] MAX78000: documentation and test

Adds .rST documentation and a functional test for the MAX78000FTHR machine as requested by Peter Maydell. Jackson Donaldson (2): docs/system: arm: Add max78000 board description tests/functional: Add a test for the MAX78000 arm machine docs/system/arm/max78000.rst | 35 +

[PATCH 2/2] tests/functional: Add a test for the MAX78000 arm machine

Runs a binary from the max78000test repo used in developing the qemu implementation of the max78000 to verify that the machine and implemented devices generally still work. Signed-off-by: Jackson Donaldson --- tests/functional/meson.build | 1 + tests/functional/test_arm_max78000ft

Re: [PATCH 1/4] target/i386: move max_features to class

On 7/11/2025 8:06 AM, Paolo Bonzini wrote: max_features is always set to true for instances created by -cpu max or -cpu host; it's always false for other classes. Therefore it can be turned into a field in the X86CPUClass. Signed-off-by: Paolo Bonzini missed one place: 8<--

Re: [PULL 0/4] loongarch-to-apply queue

0400) are available in the Git repository at: https://github.com/bibo-mao/qemu.git tags/pull-loongarch-20250710 for you to fetch changes up to 8ad757642e3a8a283edc29efec73b9bd57fdb365: target/loongarch: Remove unnecessary page size validity checking (2025-07-10 16:3

[PATCH 4/4] target/i386: move accel_cpu_instance_init to .instance_init

With the reordering of instance_post_init callbacks that is new in 10.1 accel_cpu_instance_init must execute in .instance_init as is already the case for RISC-V. Otherwise, for example, setting the vendor property is broken when using KVM or Hypervisor.framework, because KVM sets it *after* the us

[PATCH 3/4] target/i386: allow reordering max_x86_cpu_initfn vs accel CPU init

The PMU feature is only supported by KVM, so move it there. And since all accelerators other than TCG overwrite the vendor, set it in max_x86_cpu_initfn only if it has not been initialized by the superclass. This makes it possible to run max_x86_cpu_initfn after accelerator init. Signed-off-by:

[PATCH 2/4] target/i386: nvmm, whpx: add accel/CPU class that sets host vendor

NVMM and WHPX are virtualizers, and therefore they need to use (at least by default) the host vendor for the guest CPUID. Add a cpu_instance_init implementation to these accelerators. Signed-off-by: Paolo Bonzini --- target/i386/cpu.c | 8 +++- target/i386/nvmm/nvmm-all.c | 23 +++

[PATCH 1/4] target/i386: move max_features to class

max_features is always set to true for instances created by -cpu max or -cpu host; it's always false for other classes. Therefore it can be turned into a field in the X86CPUClass. Signed-off-by: Paolo Bonzini --- target/i386/cpu.h | 2 +- target/i386/cpu.c | 5 +++-- target/i386

[PATCH 0/4] target/i386: fix position of accel_cpu_instance_init

With the reordering of instance_post_init callbacks that is new in 10.1 accel_cpu_instance_init must execute in .instance_init as is already the case for RISC-V. Otherwise, for example, setting the vendor property is broken when using KVM or Hypervisor.framework. Adjust x86 code to allow this mov

Re: [PATCH v7 00/12] hw/arm/virt: Add support for user creatable SMMUv3 device

Hi Peter, On Thu, Jul 10, 2025 at 12:48:20PM +0100, Peter Maydell wrote: > On Thu, 10 Jul 2025 at 11:10, Shameerali Kolothum Thodi > > > Changes from v6: > > > https://lore.kernel.org/qemu-devel/20250703084643.85740-1- > > > shameerali.kolothum.th...@huawei.com/ > > > > > > 1. Fixed the warning ca

Re: [PATCH v7 07/12] hw/pci: Introduce pci_setup_iommu_per_bus() for per-bus IOMMU ops retrieval

On Tue, Jul 08, 2025 at 04:40:50PM +0100, Shameer Kolothum wrote: > Currently, pci_setup_iommu() registers IOMMU ops for a given PCIBus. > However, when retrieving IOMMU ops for a device using > pci_device_get_iommu_bus_devfn(), the function checks the parent_dev > and fetches IOMMU ops from the pa

Re: [PATCH v7 07/12] hw/pci: Introduce pci_setup_iommu_per_bus() for per-bus IOMMU ops retrieval

On Thu, Jul 10, 2025 at 09:40:28PM +, Shameerali Kolothum Thodi wrote: > > So, the logic is trying to avoid: > > "iommu_bus = parent_bus;" > > for a case that parent_bus (pcie.0) having its own IOMMU. > > > > But shouldn't it be just "if (parent_bus->iommu_per_bus)"? > > > > Why does

[PATCH] tcg: Use uintptr_t in tcg_malloc implementation

Avoid ubsan failure with clang-20, tcg.h:715:19: runtime error: applying non-zero offset 64 to null pointer by not using pointers. Cc: Ilya Leoshkevich Signed-off-by: Richard Henderson --- Supercedes: 20250618183759.9197-1-...@linux.ibm.com ("[PATCH v2] tcg: Remove NULL arithmetic in tcg_mall

RE: [PATCH v7 07/12] hw/pci: Introduce pci_setup_iommu_per_bus() for per-bus IOMMU ops retrieval

> -Original Message- > From: Nicolin Chen > Sent: Thursday, July 10, 2025 5:56 PM > To: Shameerali Kolothum Thodi > Cc: Donald Dutile ; qemu-...@nongnu.org; qemu- > de...@nongnu.org; eric.au...@redhat.com; peter.mayd...@linaro.org; > j...@nvidia.com; berra...@redhat.com; imamm...@redha

Re: [PATCH] hw/s390x/s390-pci-bus.c: Use g_assert_not_reached() in functions taking an ett

On 7/10/25 12:15 PM, Peter Maydell wrote: > The s390-pci-bus.c code, Coverity complains about a possible overflow > because get_table_index() can return -1 if the ett value passed in is > not one of the three permitted ZPCI_ETT_PT, ZPCI_ETT_ST, ZPCI_ETT_RT, > but the caller in table_translate() doe

[PATCH v6 2/6] target/arm: Add FEAT_MEC registers

Add all FEAT_MEC registers. To work properly, FEAT_MEC also depends on FEAT_SCTLR2 and FEAT_TCR2, which are not implemented in this commit. The bits in SCTLR2 and TCR2 control which translation regimes use MECIDs, and determine which MECID is selected and will be implemented in subsequent commits.

[PATCH-for-10.1 v6 0/6] target/arm: Add FEAT_MEC to max cpu

Since v4: - Moved MECID_WIDTH from cpu.h to internal.h - Fixed stray ';'s in access and write functions - Use of GET_IDREG/FIELD_DP64/SET_IDREG for setting feature in ID regs - Sorted correctly isar_feature_aa64_* AA64MMFR3 tests - Simplified/unified accessfn for cache instructions - Fixed how cac

[PATCH v6 3/6] target/arm: Add FEAT_SCTLR2

Add FEAT_SCTLR2, which introduces the SCTLR2_EL1, SCTLR2_EL2, and SCTLR2_EL3 registers. These registers are extensions of the SCTLR_ELx ones. Because the bits in these registers depend on other CPU features, and only FEAT_MEC is supported at the moment, this commit only implements the EMEC bits in

[PATCH v6 4/6] target/arm: Add FEAT_TCR2

Add FEAT_TCR2, which introduces the TCR2_EL1 and TCR2_EL2 registers. These registers are extensions of the TCR_ELx registers and provide top-level control of the EL10 and EL20 translation regimes. Since the bits in these registers depend on other CPU features, and only FEAT_MEC is supported at the

[PATCH v6 5/6] target/arm: Implement FEAT_MEC cache instructions

This commit implements the two cache maintenance instructions introduced by FEAT_MEC, DC CIPAE and DC CIGDPAE. Because QEMU does not model the cache topology, all cache maintenance instructions are implemented as NOPs, hence these new instructions are implemented as NOPs too. Signed-off-by: Gusta

[PATCH v6 6/6] target/arm: Advertise FEAT_MEC in cpu max

Advertise FEAT_MEC in AA64MMFR3 ID register for the Arm64 cpu max as a first step to fully support FEAT_MEC. The FEAT_MEC is an extension to FEAT_RME that implements multiple Memory Encryption Contexts (MEC) so the memory in a realm can be encrypted and accessing it from the wrong encryption conte

[PATCH v6 1/6] target/arm: Add the MECEn SCR_EL3 bit

The MECEn bit in SCR_EL3 enables access to the EL2 MECID registers from EL2, so add it to the SCR mask list to use it later on. Signed-off-by: Gustavo Romero Reviewed-by: Richard Henderson --- target/arm/cpu.h | 1 + 1 file changed, 1 insertion(+) diff --git a/target/arm/cpu.h b/target/arm/cpu

[PATCH v2 1/2] target/i386: Add TSA attack variants TSA-SQ and TSA-L1

Transient Scheduler Attacks (TSA) are new speculative side channel attacks related to the execution timing of instructions under specific microarchitectural conditions. In some cases, an attacker may be able to use this timing information to infer data from other contexts, resulting in information

Re: [PATCH] meson: Add most 3rd-party includes as system includes

Am 3. Juli 2025 06:25:11 UTC schrieb Bernhard Beschow : > > >Am 17. Juni 2025 20:34:35 UTC schrieb Bernhard Beschow : >>When compiling QEMU against fuse3-3.17.1 with --enable-werror the build fails >>with: >> >> In file included from ../src/block/export/fuse.c:33: >> /usr/include/fuse3/fuse.h:

Re: [PATCH v4] Support madvise(MADV_DONTDUMP) when creating core dumps for qemu-user

On 5/6/25 11:34, Jon Wilson wrote: +case MADV_DONTDUMP: +if (len > 0) { +/* + * To set the page permissons, we must OR our new flags with the + * existing flags. Only mark the pages as PAGE_DONTDUMP if the + * entire range has the same f

[PATCH v2 2/2] target/i386: Add TSA feature flag verw-clear

Transient Scheduler Attacks (TSA) are new speculative side channel attacks related to the execution timing of instructions under specific microarchitectural conditions. In some cases, an attacker may be able to use this timing information to infer data from other contexts, resulting in information

Re: [PATCH] hw/s390x/s390-pci-bus.c: Use g_assert_not_reached() in functions taking an ett

On Thu, 10 Jul 2025 17:15:52 +0100 Peter Maydell wrote: > The s390-pci-bus.c code, Coverity complains about a possible overflow > because get_table_index() can return -1 if the ett value passed in is > not one of the three permitted ZPCI_ETT_PT, ZPCI_ETT_ST, ZPCI_ETT_RT, > but the caller in table

Re: [PATCH] USB MSD: Set s->req to NULL after handling a packet

On Thu, 10 Jul 2025 at 18:54, Hannes Bredberg wrote: > > This fixes compatibility for OSes which enqueue multiple data transfers > on the same endpoint without waiting for the previous one to be ACKed by > the mass storage device. Which OSes are these? If there's a specific one that users might b

Re: [PATCH 0/2] linux-user/gen-vdso: minor error handling improvements

On Thu, 10 Jul 2025 at 18:58, Richard Henderson wrote: > > On 7/10/25 11:07, Peter Maydell wrote: > > These two small patches improve the error handling in the gen-vdso > > program. Error handling isn't particularly critical here because > > the tool only gets run during the QEMU build process on

Re: [PATCH 2/2] linux-user/gen-vdso: Don't write off the end of buf[]

On Thu, 10 Jul 2025 at 18:07, Peter Maydell wrote: > > In gen-vdso we load in a file and assume it's a valid ELF file. In > particular we assume it's big enough to be able to read the ELF > information in e_ident in the ELF header. > > Add a check that the total file length is at least big enough

Re: [PATCH 1/1] linux-user: Hold the fd-trans lock across fork

On 3/14/25 06:47, Geoffrey Thomas wrote: If another thread is holding target_fd_trans_lock during a fork, then the lock becomes permanently locked in the child and the emulator deadlocks at the next interaction with the fd-trans table. As with other locks, acquire the lock in fork_start() and rel

Re: [PATCH] linux-user/mips/o32: Drop sa_restorer functionality

On 7/9/25 14:57, Thomas Weißschuh wrote: The Linux kernel dropped support for sa_restorer on O32 MIPS in the release 2.5.48 because it was unused. See the comment in arch/mips/include/uapi/asm/signal.h. Applications using the kernels UAPI headers will not reserve enough space for qemu-user to co

Re: [PATCH] target/arm: Correct encoding of Debug Communications Channel registers

On 7/8/25 08:10, Peter Maydell wrote: We don't implement the Debug Communications Channel (DCC), but we do attempt to provide dummy versions of its system registers so that software that tries to access them doesn't fall over. However, we got the tx/rx register definitions wrong. These should be

Re: [PATCH 0/2] linux-user/gen-vdso: minor error handling improvements

On 7/10/25 11:07, Peter Maydell wrote: These two small patches improve the error handling in the gen-vdso program. Error handling isn't particularly critical here because the tool only gets run during the QEMU build process on input that we trust (because we generated it by calling a compiler for

Re: [PATCH] linux-user: Check for EFAULT failure in nanosleep

On 7/10/25 10:43, Peter Maydell wrote: target_to_host_timespec() returns an error if the memory the guest passed us isn't actually readable. We check for this everywhere except the callsite in the TARGET_NR_nanosleep case, so this mistake was caught by a Coverity heuristic. Add the missing erro

Re: [PATCH] linux-user: Implement fchmodat2 syscall

On 7/10/25 05:31, Peter Maydell wrote: The fchmodat2 syscall is new from Linux 6.6; it is like the existing fchmodat syscall except that it takes a flags parameter. Signed-off-by: Peter Maydell --- v1->v2: don't bother with trying to fall back to libc fchmodat(); add missing braces for if() Q

Re: [PATCH] linux-user: Check for EFAULT failure in nanosleep

On 7/10/25 10:43, Peter Maydell wrote: target_to_host_timespec() returns an error if the memory the guest passed us isn't actually readable. We check for this everywhere except the callsite in the TARGET_NR_nanosleep case, so this mistake was caught by a Coverity heuristic. Add the missing erro

Re: [PATCH 2/2] linux-user/gen-vdso: Don't write off the end of buf[]

On 7/10/25 11:07, Peter Maydell wrote: In gen-vdso we load in a file and assume it's a valid ELF file. In particular we assume it's big enough to be able to read the ELF information in e_ident in the ELF header. Add a check that the total file length is at least big enough for all the e_ident b

Re: [PATCH 1/2] linux-user/gen-vdso: Handle fseek() failure

On 7/10/25 11:07, Peter Maydell wrote: Coverity points out that we don't check for fseek() failure in gen-vdso.c, and so we might pass -1 to malloc(). Add the error checking. (This is a standalone executable that doesn't link against glib, so we can't do the easy thing and use g_file_get_content

[PATCH] hw/display/framebuffer: Add cast to force 64x64 multiply

In framebuffer_update_display(), Coverity complains because we multiply two values of type 'int' (which will be done as a 32x32 multiply and so in theory might overflow) and then add the result to a ram_addr_t, which can be 64 bits. 4GB framebuffers are not plausible anyway, but keep Coverity happ

[PATCH] target/arm: Remove helper_sme2_luti4_4b

This function isn't used. Resolves: Coverity CID 1612139 Signed-off-by: Richard Henderson --- target/arm/tcg/helper.h | 1 - target/arm/tcg/vec_helper.c | 1 - 2 files changed, 2 deletions(-) diff --git a/target/arm/tcg/helper.h b/target/arm/tcg/helper.h index d9565c8069..0a006d9514 100644

Re: [PATCH v3 02/20] hw/pci: Introduce pci_device_get_viommu_cap()

On Thu, Jul 10, 2025 at 01:07:11PM -0400, Donald Dutile wrote: > > > > If not, maybe go a bit further like "VIOMMU_CAP_HW_NESTED_S1"? > > > > > > I am not sure the _S1 part makes much sense in ARM case. It doesn't matter > > > whether the Guest SMMUv3 is configured in s1/s2 or nested for this CAP.

Re: [PATCH v3 02/20] hw/pci: Introduce pci_device_get_viommu_cap()

On Thu, Jul 10, 2025 at 08:11:28AM +, Shameerali Kolothum Thodi wrote: > > So I suggested: > > /* hardware-accelerated nested stage-1 page table support */ > > VIOMMU_CAP_NESTED_S1 = BIT_ULL(0), > > > > which it should be clear IMHO. > > > > If not, maybe go a bit further like "VIOMM

[PATCH] USB MSD: Set s->req to NULL after handling a packet

This fixes compatibility for OSes which enqueue multiple data transfers on the same endpoint without waiting for the previous one to be ACKed by the mass storage device. Signed-off-by: Hannes Bredberg --- hw/usb/dev-storage.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/

Re: [PATCH v3 02/20] hw/pci: Introduce pci_device_get_viommu_cap()

oops, inadvertently hit send before I could add reply... apologies... reply below... On 7/10/25 1:01 PM, Donald Dutile wrote: On 7/10/25 4:11 AM, Shameerali Kolothum Thodi wrote: -Original Message- From: Nicolin Chen Sent: Wednesday, July 9, 2025 8:20 PM To: Donald Dutile Cc: Zh

[PATCH 1/2] linux-user/gen-vdso: Handle fseek() failure

Coverity points out that we don't check for fseek() failure in gen-vdso.c, and so we might pass -1 to malloc(). Add the error checking. (This is a standalone executable that doesn't link against glib, so we can't do the easy thing and use g_file_get_contents().) Coverity: CID 1523742 Signed-off-b

Re: [PATCH v7 02/12] hw/arm/smmu-common: Check SMMU has PCIe Root Complex association

On Tue, Jul 08, 2025 at 04:40:45PM +0100, Shameer Kolothum wrote: > We only allow default PCIe Root Complex(pcie.0) or pxb-pcie based extra > root complexes to be associated with SMMU. > > Although this change does not affect functionality at present, it is > required when we add support for user-

[PATCH 0/2] linux-user/gen-vdso: minor error handling improvements

These two small patches improve the error handling in the gen-vdso program. Error handling isn't particularly critical here because the tool only gets run during the QEMU build process on input that we trust (because we generated it by calling a compiler for the guest architecture), but these were

[PATCH 2/2] linux-user/gen-vdso: Don't write off the end of buf[]

In gen-vdso we load in a file and assume it's a valid ELF file. In particular we assume it's big enough to be able to read the ELF information in e_ident in the ELF header. Add a check that the total file length is at least big enough for all the e_ident bytes, which is good enough for the code i

Re: [PATCH v3 02/20] hw/pci: Introduce pci_device_get_viommu_cap()

On 7/10/25 4:11 AM, Shameerali Kolothum Thodi wrote: -Original Message- From: Nicolin Chen Sent: Wednesday, July 9, 2025 8:20 PM To: Donald Dutile Cc: Zhenzhong Duan ; qemu- de...@nongnu.org; alex.william...@redhat.com; c...@redhat.com; eric.au...@redhat.com; m...@redhat.com; jaso

Re: [PATCH v7 02/12] hw/arm/smmu-common: Check SMMU has PCIe Root Complex association

On Thu, Jul 10, 2025 at 07:27:10AM +, Shameerali Kolothum Thodi wrote: > > On Wed, Jul 09, 2025 at 08:08:49AM +, Shameerali Kolothum Thodi > > wrote: > > > > On Tue, Jul 08, 2025 at 04:40:45PM +0100, Shameer Kolothum wrote: > > > > > @@ -937,11 +939,32 @@ static void smmu_base_realize(Devic

Re: [PATCH v7 07/12] hw/pci: Introduce pci_setup_iommu_per_bus() for per-bus IOMMU ops retrieval

On 7/10/25 12:21 PM, Shameerali Kolothum Thodi wrote: -Original Message- From: Donald Dutile Sent: Thursday, July 10, 2025 5:00 PM To: Shameerali Kolothum Thodi ; Nicolin Chen Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org; eric.au...@redhat.com; peter.mayd...@linaro.org; j...@nvi

Re: [PATCH v7 07/12] hw/pci: Introduce pci_setup_iommu_per_bus() for per-bus IOMMU ops retrieval

On Thu, Jul 10, 2025 at 04:21:41PM +, Shameerali Kolothum Thodi wrote: > > >> On Wed, Jul 09, 2025 at 08:20:35AM +, Shameerali Kolothum Thodi > > >> wrote: > > On Tue, Jul 08, 2025 at 04:40:50PM +0100, Shameer Kolothum wrote: > > > @@ -2909,6 +2909,19 @@ static void > > pci_de

Re: [PATCH v5 5/6] target/arm: Implement FEAT_MEC cache instructions

On 7/10/25 10:38, Gustavo Romero wrote: This commit implements the two cache maintenance instructions introduced by FEAT_MEC, DC CIPAE and DC CIGDPAE. Because QEMU does not model the cache topology, all cache maintenance instructions are implemented as NOPs, hence these new instructions are impl

Re: [PATCH v5 3/6] target/arm: Add FEAT_SCTLR2

On 7/10/25 10:38, Gustavo Romero wrote: +static CPAccessResult sctlr2_el2_access(CPUARMState *env, +const ARMCPRegInfo *ri, +bool isread) +{ +if (arm_current_el(env) < 3 && !(env->cp15.scr_el3 & SCR_SCTLR2EN)) { +

Re: [PATCH v5 4/6] target/arm: Add FEAT_TCR2

On 7/10/25 10:38, Gustavo Romero wrote: +static CPAccessResult tcr2_el2_access(CPUARMState *env, const ARMCPRegInfo *ri, + bool isread) +{ +if (arm_current_el(env) < 3 && !(env->cp15.scr_el3 & SCR_TCR2EN)) { +return CP_ACCESS_TRAP_EL3; +} Sti

[PATCH v5 6/6] target/arm: Advertise FEAT_MEC in cpu max

Advertise FEAT_MEC in AA64MMFR3 ID register for the Arm64 cpu max as a first step to fully support FEAT_MEC. The FEAT_MEC is an extension to FEAT_RME that implements multiple Memory Encryption Contexts (MEC) so the memory in a realm can be encrypted and accessing it from the wrong encryption conte

[PATCH v5 5/6] target/arm: Implement FEAT_MEC cache instructions

This commit implements the two cache maintenance instructions introduced by FEAT_MEC, DC CIPAE and DC CIGDPAE. Because QEMU does not model the cache topology, all cache maintenance instructions are implemented as NOPs, hence these new instructions are implemented as NOPs too. Signed-off-by: Gusta

  1   2   3   >