Re: [PATCH v4 15/15] hw/vmapple/vmapple: Add vmapple machine type

On 2024/10/24 19:28, Phil Dennis-Jordan wrote: From: Alexander Graf Apple defines a new "vmapple" machine type as part of its proprietary macOS Virtualization.Framework vmm. This machine type is similar to the virt one, but with subtle differences in base devices, a few special vmapple device a

Re: [PATCH v4 14/15] hw/block/virtio-blk: Replaces request free function with g_free

On 2024/10/24 19:28, Phil Dennis-Jordan wrote: The virtio_blk_free_request() function has been a 1-liner forwarding to g_free() for a while now. We may as well call g_free on the request pointer directly. Signed-off-by: Phil Dennis-Jordan Reviewed-by: Akihiko Odaki

Re: [PATCH v4 13/15] hw/vmapple/virtio-blk: Add support for apple virtio-blk

On 2024/10/24 19:28, Phil Dennis-Jordan wrote: From: Alexander Graf Apple has its own virtio-blk PCI device ID where it deviates from the official virtio-pci spec slightly: It puts a new "apple type" field at a static offset in config space and introduces a new barrier command. This patch firs

Re: [PATCH v4 12/15] hw/vmapple/cfg: Introduce vmapple cfg region

On 2024/10/24 19:28, Phil Dennis-Jordan wrote: From: Alexander Graf Instead of device tree or other more standardized means, VMApple passes platform configuration to the first stage boot loader in a binary encoded format that resides at a dedicated RAM region in physical address space. This pa

Re: [PATCH 0/2] arm: Add collie and sx functional tests

On 10/25/24 21:47, Philippe Mathieu-Daudé wrote: On 25/10/24 12:25, Jan Lübbe wrote: On Fri, 2024-10-25 at 06:59 -0700, Guenter Roeck wrote: On 10/25/24 02:57, Jan Lübbe wrote: On Fri, 2024-10-25 at 08:55 +0200, Cédric Le Goater wrote: On 10/24/24 19:59, Philippe Mathieu-Daudé wrote: Cc'ing

Re: [PATCH v4 10/15] hw/vmapple/aes: Introduce aes engine

On 2024/10/24 19:28, Phil Dennis-Jordan wrote: From: Alexander Graf VMApple contains an "aes" engine device that it uses to encrypt and decrypt its nvram. It has trivial hard coded keys it uses for that purpose. Add device emulation for this device model. Signed-off-by: Alexander Graf Signed

Re: [PATCH v2 1/8] Add CP0 MemoryMapID register implementation

On 18/10/24 10:18, Aleksandar Rakic wrote: Add CP0 MemoryMapID register implementation. Cherry-picked 9e0cb40adb110c2c76e2e97719ba8afcce72bcf5 from https://github.com/MIPS/gnutools-qemu Signed-off-by: Yongbok Kim Signed-off-by: Aleksandar Markovic Signed-off-by: Aleksandar Rakic --- target

Re: [PATCH 16/21] target/alpha: Explicitly set 2-NaN propagation rule

On 25/10/24 11:12, Peter Maydell wrote: Set the NaN propagation rule explicitly for the float_status word used in this target. This is a no-behaviour-change commit, so we retain the existing behaviour of x87-style pick-largest-significand NaN propagation. This is however not the architecturally

Re: [PATCH v4 04/15] hw/display/apple-gfx: Adds configurable mode list

On 2024/10/24 19:28, Phil Dennis-Jordan wrote: This change adds a property 'display_modes' on the graphics device which permits specifying a list of display modes. (screen resolution and refresh rate) The property is an array of a custom type to make the syntax slightly less awkward to use, for

Re: [PATCH v4 09/15] gpex: Allow more than 4 legacy IRQs

On 2024/10/24 19:28, Phil Dennis-Jordan wrote: From: Alexander Graf Some boards such as vmapple don't do real legacy PCI IRQ swizzling. Instead, they just keep allocating more board IRQ lines for each new legacy IRQ. Let's support that mode by giving instantiators a new "nr_irqs" property they

Re: [PATCH v4 02/15] hw/display/apple-gfx: Introduce ParavirtualizedGraphics.Framework support

On 2024/10/26 4:43, Phil Dennis-Jordan wrote: On Fri, 25 Oct 2024 at 08:03, Akihiko Odaki > wrote: On 2024/10/24 19:28, Phil Dennis-Jordan wrote: > MacOS provides a framework (library) that allows any vmm to implement a > paravirtualized 3d g

Re: [PATCH 18/21] target/microblaze: Explicitly set 2-NaN propagation rule

On 25/10/24 11:12, Peter Maydell wrote: Set the NaN propagation rule explicitly for the float_status word used in the microblaze target. This is probably not the architecturally correct behaviour, but since this is a no-behaviour-change patch, we leave a TODO note to that effect. Signed-off-by:

Re: [PATCH 10/21] target/m68k: Initialize float_status fields in gdb set/get functions

On 25/10/24 11:12, Peter Maydell wrote: In cf_fpu_gdb_get_reg() and cf_fpu_gdb_set_reg() we use a temporary float_status variable to pass to floatx80_to_float64() and float64_to_floatx80(), but we don't initialize it, meaning that those functions could access uninitialized data. Zero-init the st

Re: [PATCH 20/21] target/rx: Explicitly set 2-NaN propagation rule

On 25/10/24 11:12, Peter Maydell wrote: Set the NaN propagation rule explicitly for the float_status word used in the rx target. This not the architecturally correct behaviour, but since this is a no-behaviour-change patch, we leave a TODO note to that effect. Signed-off-by: Peter Maydell ---

Re: [PATCH 11/21] target/sparc: Move cpu_put_fsr(env, 0) call to reset

On 25/10/24 11:12, Peter Maydell wrote: Currently we call cpu_put_fsr(0) in sparc_cpu_realizefn(), which initializes various fields in the CPU struct: * fsr_cexc_ftt * fcc[] * fsr_qne * fsr It also sets the rounding mode in env->fp_status. This is largely pointless, because when we later

Re: [PATCH 19/21] target/openrisc: Explicitly set 2-NaN propagation rule

On 25/10/24 11:12, Peter Maydell wrote: Set the NaN propagation rule explicitly for the float_status word used in the openrisc target. Signed-off-by: Peter Maydell --- target/openrisc/cpu.c | 6 ++ fpu/softfloat-specialize.c.inc | 2 +- 2 files changed, 7 insertions(+), 1 delet

Re: [PATCH v3 2/2] cpu: ensure we don't call start_exclusive from cpu_exec

On 25/10/24 14:58, Pierrick Bouvier wrote: Reviewed-by: Richard Henderson Signed-off-by: Pierrick Bouvier --- cpu-common.c | 3 +++ 1 file changed, 3 insertions(+) Reviewed-by: Philippe Mathieu-Daudé

Re: [PATCH 09/21] target/m68k: Explicitly set 2-NaN propagation rule

On 25/10/24 11:12, Peter Maydell wrote: Explicitly set the 2-NaN propagation rule on env->fp_status and on the temporary fp_status that we use in frem (since we pass that to a division operation function). --- target/m68k/cpu.c | 16 target/m68k/fpu_helper.c

Re: [PATCH 0/2] arm: Add collie and sx functional tests

On 25/10/24 12:25, Jan Lübbe wrote: On Fri, 2024-10-25 at 06:59 -0700, Guenter Roeck wrote: On 10/25/24 02:57, Jan Lübbe wrote: On Fri, 2024-10-25 at 08:55 +0200, Cédric Le Goater wrote: On 10/24/24 19:59, Philippe Mathieu-Daudé wrote: Cc'ing Jan. On 22/10/24 12:04, Guenter Roeck wrote: I

Re: [PATCH v4 03/15] hw/display/apple-gfx: Adds PCI implementation

On 2024/10/24 19:28, Phil Dennis-Jordan wrote: This change wires up the PCI variant of the paravirtualised graphics device, mainly useful for x86-64 macOS guests, implemented by macOS's ParavirtualizedGraphics.framework. It builds on code shared with the vmapple/mmio variant of the PVG device. S

Re: [PATCH 07/21] target/s390x: Explicitly set 2-NaN propagation rule

On 25/10/24 11:12, Peter Maydell wrote: Set the 2-NaN propagation rule explicitly in env->fpu_status. Signed-off-by: Peter Maydell --- target/s390x/cpu.c | 1 + fpu/softfloat-specialize.c.inc | 5 ++--- 2 files changed, 3 insertions(+), 3 deletions(-) Reviewed-by: Philippe Mat

Re: [PATCH 14/21] target/xtensa: Explicitly set 2-NaN propagation rule

On 25/10/24 11:12, Peter Maydell wrote: Set the NaN propagation rule explicitly in xtensa_use_first_nan(). (When we convert the softfloat pickNaNMulAdd routine to also select a NaN propagation rule at runtime, we will be able to remove the use_first_nan flag because the propagation rules will ha

Re: [PATCH 21/21] softfloat: Remove fallback rule from pickNaN()

On 25/10/24 11:12, Peter Maydell wrote: Now that all targets have been converted to explicitly set a NaN propagation rule, we can remove the set of target ifdefs (which now list every target) and clean up the references to fallback behaviour for float_2nan_prop_none. The "default" case in the sw

Re: [PATCH 22/23] dockerfiles: install bindgen from cargo on Ubuntu 22.04

On 10/25/24 13:08, Paolo Bonzini wrote: Il ven 25 ott 2024, 21:47 Pierrick Bouvier > ha scritto: >  in the end the operation of bindgen is quite deterministic, so if > the coverage is improved we can indeed install 0.60.x. For example, if

Re: [PULL 0/4] vfio queue

On Thu, 24 Oct 2024 at 06:33, Cédric Le Goater wrote: > > The following changes since commit 6f625ce2f21d6a1243065d236298277c56f972d5: > > Merge tag 'pull-request-2024-10-21' of https://gitlab.com/thuth/qemu into > staging (2024-10-21 17:12:59 +0100) > > are available in the Git repository at:

Re: [PATCH 22/23] dockerfiles: install bindgen from cargo on Ubuntu 22.04

On 10/25/24 09:02, Paolo Bonzini wrote: Because Ubuntu 22.04 has a very old version of bindgen, that does not have the important option --allowlist-file, it will not be able to use --enable-rust out of the box. Instead, install the latest version of bindgen-cli via "cargo install" in the contain

Re: [PATCH v1 2/4] accel/kvm: Keep track of the HWPoisonPage page_size

On 10/23/24 09:28, David Hildenbrand wrote: On 22.10.24 23:35, “William Roche wrote: From: William Roche Add the page size information to the hwpoison_page_list elements. As the kernel doesn't always report the actual poisoned page size, we adjust this size from the backend real page size. We

Re: [PATCH v1 3/4] system/physmem: Largepage punch hole before reset of memory pages

On 10/23/24 09:30, David Hildenbrand wrote: On 22.10.24 23:35, “William Roche wrote: From: William Roche When the VM reboots, a memory reset is performed calling qemu_ram_remap() on all hwpoisoned pages. While we take into account the recorded page sizes to repair the memory locations, a larg

Re: [PATCH v1 2/4] accel/kvm: Keep track of the HWPoisonPage page_size

On 10/23/24 09:28, David Hildenbrand wrote: On 22.10.24 23:35, “William Roche wrote: From: William Roche Add the page size information to the hwpoison_page_list elements. As the kernel doesn't always report the actual poisoned page size, we adjust this size from the backend real page size. We

[PATCH v2 2/3] tpm/tpm_tis_spi: activation for the PowerNV machines

The addition to ppc/Kconfig is for building this into the qemu-system-ppc64 binary. The enablement requires the following command line argument: -device tpm-tis-spi,tpmdev=tpm0,bus=pnv-spi-bus.4 Signed-off-by: dan tan --- hw/ppc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/pp

Re: [PATCH 2/4] x86/iommu: Make x86-iommu a singleton object

On Fri, Oct 25, 2024 at 05:55:59PM -0400, Peter Xu wrote: > On Fri, Oct 25, 2024 at 11:25:23AM +0200, Markus Armbruster wrote: > > Peter Xu writes: > > > > > X86 IOMMUs cannot be created more than one on a system yet. Make it a > > > singleton so it guards the system from accidentally create yet

Re: [PATCH 1/4] qom: TYPE_SINGLETON interface

On Fri, Oct 25, 2024 at 05:22:01PM +0100, Daniel P. Berrangé wrote: > On Fri, Oct 25, 2024 at 12:17:02PM -0400, Peter Xu wrote: > > On Fri, Oct 25, 2024 at 10:51:21AM +0100, Daniel P. Berrangé wrote: > > > > diff --git a/qom/qom-qmp-cmds.c b/qom/qom-qmp-cmds.c > > > > index e91a235347..ecc1cf781c 1

Re: [PATCH 02/21] tests/fp: Explicitly set 2-NaN propagation rule

On 25/10/24 11:12, Peter Maydell wrote: Explicitly set a 2-NaN propagation rule in the softfloat tests. In meson.build we put -DTARGET_ARM in fpcflags, and so we should select here the Arm propagation rule of float_2nan_prop_s_ab. Signed-off-by: Peter Maydell --- tests/fp/fp-bench.c | 2

Re: [PATCH 2/4] x86/iommu: Make x86-iommu a singleton object

On Fri, Oct 25, 2024 at 11:25:23AM +0200, Markus Armbruster wrote: > Peter Xu writes: > > > X86 IOMMUs cannot be created more than one on a system yet. Make it a > > singleton so it guards the system from accidentally create yet another > > IOMMU object when one already presents. > > > > Now if

[PATCH v2 0/3] *** TPM TIS SPI pull request ***

Version 2 summary, addressed the following review comments: - break up patch into 3 separate commits; - add more details in the commit logs; - I added links to the TCG TPM standard documents as this device model communicates to the TPM device (hw / swtpm) via tpm_t

[PATCH v2 1/3] tpm/tpm_tis_spi: Support TPM for SPI (Serial Peripheral Interface)

Implement support for TPM via SPI interface. The SPI bus master is provided by PowerNV SPI device which is an SSI peripheral. It can uses the tpm_emulator driver backend with the external swtpm. Although the implementation is endian neutral, the SPI bus master provider, pnv_spi.c is only supported

Re: [PATCH 19/23] rust: do not use --generate-cstr

On 10/25/24 13:10, Michael Tokarev wrote: 25.10.2024 23:06, Pierrick Bouvier wrote: On 10/25/24 13:03, Michael Tokarev wrote: 25.10.2024 19:02, Paolo Bonzini wrote: --generate-cstr is a good idea and generally the right thing to do, but it is not available in Debian 12 and Ubuntu 22.04.  Work

Re: [PATCH 22/23] dockerfiles: install bindgen from cargo on Ubuntu 22.04

Il ven 25 ott 2024, 22:14 Pierrick Bouvier ha scritto: > > Here: > > > https://lore.kernel.org/qemu-devel/20241015133925.311587-2-berra...@redhat.com/ > > Good. As there is no based-on tag in the cover letter, I expected this > to apply on current master. > Yes, it's based on my next pull reques

Re: [PATCH 19/23] rust: do not use --generate-cstr

25.10.2024 23:06, Pierrick Bouvier wrote: On 10/25/24 13:03, Michael Tokarev wrote: 25.10.2024 19:02, Paolo Bonzini wrote: --generate-cstr is a good idea and generally the right thing to do, but it is not available in Debian 12 and Ubuntu 22.04.  Work around the absence. Can't we just install

Re: [PATCH 19/23] rust: do not use --generate-cstr

Il ven 25 ott 2024, 22:03 Michael Tokarev ha scritto: > 25.10.2024 19:02, Paolo Bonzini wrote: > > --generate-cstr is a good idea and generally the right thing to do, > > but it is not available in Debian 12 and Ubuntu 22.04. Work around > > the absence. > > Can't we just install a more recent b

[PATCH v2 3/3] tests/qtest/tpm: add unit test to tis-spi

Add qtest cases to exercise main TPM locality functionality The TPM device emulation is provided by swtpm, which is TCG TPM 2.0, and TCG TPM TIS compliant. See https://trustedcomputinggroup.org/wp-content/uploads/TCG_PC_Client_Platform_TPM_Profile_PTP_2.0_r1.03_v22.pdf https://trustedcomputinggroup

Re: [PATCH 23/23] ci: enable rust in the Debian and Ubuntu system build job

On 10/25/24 09:02, Paolo Bonzini wrote: We have fixed all incompatibilities with older versions of rustc and bindgen. Enable Rust on Debian to check that the minimum supported version of Rust is indeed 1.63.0, and 0.60.x for bindgen. Signed-off-by: Paolo Bonzini --- .gitlab-ci.d/buildtest.ym

Re: [PATCH 22/23] dockerfiles: install bindgen from cargo on Ubuntu 22.04

Il ven 25 ott 2024, 21:47 Pierrick Bouvier ha scritto: > > in the end the operation of bindgen is quite deterministic, so if > > the coverage is improved we can indeed install 0.60.x. For example, if > > we think that user on Debian 12 might use distro bindgen together with a > > recent rustc (i

Re: [PATCH 19/23] rust: do not use --generate-cstr

On 10/25/24 13:03, Michael Tokarev wrote: 25.10.2024 19:02, Paolo Bonzini wrote: --generate-cstr is a good idea and generally the right thing to do, but it is not available in Debian 12 and Ubuntu 22.04. Work around the absence. Can't we just install a more recent bindgen and use all the curr

Re: [PATCH 19/23] rust: do not use --generate-cstr

25.10.2024 19:02, Paolo Bonzini wrote: --generate-cstr is a good idea and generally the right thing to do, but it is not available in Debian 12 and Ubuntu 22.04. Work around the absence. Can't we just install a more recent bindgen and use all the current features of it, like it's done in patch

Re: [PATCH 22/23] dockerfiles: install bindgen from cargo on Ubuntu 22.04

Il ven 25 ott 2024, 20:51 Pierrick Bouvier ha scritto: > Hi Paolo, > > On 10/25/24 09:02, Paolo Bonzini wrote: > > Because Ubuntu 22.04 has a very old version of bindgen, that > > does not have the important option --allowlist-file, it will > > not be able to use --enable-rust out of the box. In

Re: [PATCH 22/23] dockerfiles: install bindgen from cargo on Ubuntu 22.04

On 10/25/24 12:35, Paolo Bonzini wrote: Il ven 25 ott 2024, 20:51 Pierrick Bouvier > ha scritto: Hi Paolo, On 10/25/24 09:02, Paolo Bonzini wrote: > Because Ubuntu 22.04 has a very old version of bindgen, that > does not have the importan

Re: [PATCH 04/21] target/mips: Explicitly set 2-NaN propagation rule

On 25/10/24 11:12, Peter Maydell wrote: Set the 2-NaN propagation rule explicitly in the float_status words we use. For active_fpu.fp_status, we do this in a new fp_reset() function which mirrors the existing msa_reset() function in doing "first call restore to set the fp status parts that depen

Re: [PATCH v4 02/15] hw/display/apple-gfx: Introduce ParavirtualizedGraphics.Framework support

On Fri, 25 Oct 2024 at 08:03, Akihiko Odaki wrote: > On 2024/10/24 19:28, Phil Dennis-Jordan wrote: > > MacOS provides a framework (library) that allows any vmm to implement a > > paravirtualized 3d graphics passthrough to the host metal stack called > > ParavirtualizedGraphics.Framework (PVG). T

Re: [PATCH 23/23] ci: enable rust in the Debian and Ubuntu system build job

On 10/25/24 12:27, Paolo Bonzini wrote: Il ven 25 ott 2024, 20:55 Pierrick Bouvier > ha scritto: On 10/25/24 09:02, Paolo Bonzini wrote: > We have fixed all incompatibilities with older versions of rustc > and bindgen.  Enable Rust on Debian t

Re: [PATCH 23/23] ci: enable rust in the Debian and Ubuntu system build job

Il ven 25 ott 2024, 20:55 Pierrick Bouvier ha scritto: > On 10/25/24 09:02, Paolo Bonzini wrote: > > We have fixed all incompatibilities with older versions of rustc > > and bindgen. Enable Rust on Debian to check that the minimum > > supported version of Rust is indeed 1.63.0, and 0.60.x for bi

Re: [PATCH v2 8/8] target/mips: Enable MSA ASE for mips64R2-generic

On 18/10/24 10:21, Aleksandar Rakic wrote: Enable MSA ASE for mips64R2-generic CPU. Cherry-picked 60f6ae8d3d685ba1ea5d301222fb72b67f39264f from https://github.com/MIPS/gnutools-qemu Signed-off-by: Faraz Shahbazker Signed-off-by: Aleksandar Rakic --- target/mips/cpu-defs.c.inc | 4 +++- 1

Re: [PATCH v2 7/8] target/mips: Enable MSA ASE for mips32r6-generic

On 18/10/24 10:20, Aleksandar Rakic wrote: Enable MSA ASE for mips32r6-generic CPU. Commit 4b3bcd016d8 added this comment: /* A generic CPU supporting MIPS32 Release 6 ISA. FIXME: Support IEEE 754-2008 FP. Eventually this should be replaced by a

Re: [PATCH 23/23] ci: enable rust in the Debian and Ubuntu system build job

On 10/25/24 11:55, Pierrick Bouvier wrote: On 10/25/24 09:02, Paolo Bonzini wrote: We have fixed all incompatibilities with older versions of rustc and bindgen. Enable Rust on Debian to check that the minimum supported version of Rust is indeed 1.63.0, and 0.60.x for bindgen. Signed-off-by: Pa

Re: cpr-transfer with caveats

On 10/25/2024 11:54 AM, Daniel P. Berrangé wrote: On Fri, Oct 25, 2024 at 11:01:27AM -0400, Steven Sistare wrote: Hi Peter, are you OK if we proceed with cpr-transfer as is, without the precreate phase? Here are the problems that motivated it: * migration test wants to enable migration events

Re: [PATCH 23/23] ci: enable rust in the Debian and Ubuntu system build job

On 10/25/24 09:02, Paolo Bonzini wrote: We have fixed all incompatibilities with older versions of rustc and bindgen. Enable Rust on Debian to check that the minimum supported version of Rust is indeed 1.63.0, and 0.60.x for bindgen. Signed-off-by: Paolo Bonzini --- .gitlab-ci.d/buildtest.ym

Re: [PATCH 22/23] dockerfiles: install bindgen from cargo on Ubuntu 22.04

Hi Paolo, On 10/25/24 09:02, Paolo Bonzini wrote: Because Ubuntu 22.04 has a very old version of bindgen, that does not have the important option --allowlist-file, it will not be able to use --enable-rust out of the box. Instead, install the latest version of bindgen-cli via "cargo install" in

Re: [PATCH 00/21] softfloat: Set 2-NaN propagation rule in float_status, not at compile time

On 10/25/24 16:59, Peter Maydell wrote: On Fri, 25 Oct 2024 at 15:49, Helge Deller wrote: On 10/25/24 16:12, Peter Maydell wrote: A summary of those TODOs and other oddities I have noticed but not tried to tackle is:> * hppa really ought to implement a CPU reset method * alpha also doe

[PATCH] target/hppa: Add CPU reset method

Add the missing CPU reset method, which resets all CPU registers and the TLB to zero. Then the CPU will switch to 32-bit mode (PSW_W bit is not set) and start execution at address 0xf004. Signed-off-by: Helge Deller diff --git a/target/hppa/cpu.c b/target/hppa/cpu.c index c38439c180..0cc696c

Re: cpr-transfer with caveats

On 10/25/2024 11:47 AM, Peter Xu wrote: On Fri, Oct 25, 2024 at 11:01:27AM -0400, Steven Sistare wrote: Hi Peter, are you OK if we proceed with cpr-transfer as is, without the precreate phase? Here are the problems that motivated it: * migration test wants to enable migration events on the des

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

On Thu, 24 Oct 2024 at 10:44, Song Gao wrote: > > The following changes since commit 6f625ce2f21d6a1243065d236298277c56f972d5: > > Merge tag 'pull-request-2024-10-21' of https://gitlab.com/thuth/qemu into > staging (2024-10-21 17:12:59 +0100) > > are available in the Git repository at: > > ht

[PATCH v2 0/2] target/i386: fix hang when using slow path for ptw_setl

Most of the details are available in first patch. Second one is there to ensure we'll have a useful error message if start_exclusive is called from cpu_exec again. I'm a bit puzzled that we never triggered this hang before. Is there something wrong with the potential slow path for ptw_setl, or is

[PATCH v2 2/2] cpu: ensure we don't call start_exclusive from cpu_exec

Signed-off-by: Pierrick Bouvier --- cpu-common.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/cpu-common.c b/cpu-common.c index 6b262233a3b..c979138fce9 100644 --- a/cpu-common.c +++ b/cpu-common.c @@ -194,6 +194,9 @@ void start_exclusive(void) CPUState *other_cpu; int running

[PATCH v2 1/2] target/i386: fix hang when using slow path for ptw_setl

When instrumenting memory accesses for plugin, we force memory accesses to use the slow path for mmu. [1] This create a situation where we end up calling ptw_setl_slow. Since this function gets called during a cpu_exec, start_exclusive then hangs. This exclusive section was introduced initially fo

Re: [PATCH v2 0/2] target/i386: fix hang when using slow path for ptw_setl

On 10/25/24 10:53, Pierrick Bouvier wrote: Most of the details are available in first patch. Second one is there to ensure we'll have a useful error message if start_exclusive is called from cpu_exec again. I'm a bit puzzled that we never triggered this hang before. Is there something wrong with

[PATCH v3 1/2] target/i386: fix hang when using slow path for ptw_setl

When instrumenting memory accesses for plugin, we force memory accesses to use the slow path for mmu [1]. This create a situation where we end up calling ptw_setl_slow. This was fixed recently in [2] but the issue still could appear out of plugins use case. Since this function gets called during a

[PATCH v3 0/2] target/i386: fix hang when using slow path for ptw_setl

Most of the details are available in first patch. Second one is there to ensure we'll have a useful error message if start_exclusive is called from cpu_exec again. I'm a bit puzzled that we never triggered this hang before. Is there something wrong with the potential slow path for ptw_setl, or is

[PATCH v3 2/2] cpu: ensure we don't call start_exclusive from cpu_exec

Reviewed-by: Richard Henderson Signed-off-by: Pierrick Bouvier --- cpu-common.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/cpu-common.c b/cpu-common.c index 6b262233a3b..0d607bbe493 100644 --- a/cpu-common.c +++ b/cpu-common.c @@ -194,6 +194,9 @@ void start_exclusive(void) CPUSt

Re: [PATCH 07/21] target/s390x: Explicitly set 2-NaN propagation rule

On Fri, 2024-10-25 at 15:12 +0100, Peter Maydell wrote: > Set the 2-NaN propagation rule explicitly in env->fpu_status. > > Signed-off-by: Peter Maydell > --- >  target/s390x/cpu.c | 1 + >  fpu/softfloat-specialize.c.inc | 5 ++--- >  2 files changed, 3 insertions(+), 3 deletions(-) >

Re: Ping: [PATCH v2 1/2] linux-user: Map low priority rt signals

On Fri, 2024-10-25 at 16:36 +0100, Richard Henderson wrote: > On 10/25/24 10:32, Ilya Leoshkevich wrote: > > On Tue, 2024-02-13 at 07:51 +0100, Philippe Mathieu-Daudé wrote: > > > Cc'ing Brian & Taylor > > > > > > On 12/2/24 21:45, Ilya Leoshkevich wrote: > > > > Some applications want to use low

Re: qcrypto_ivgen mem leak and possible issue?

On Fri, 25 Oct 2024 17:23:57 +0100 Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= wrote: > > On Fri, Oct 25, 2024 at 01:06:01PM -0300, Matheus Tavares Bernardino wrote: > > Hi, > > > > Since e3c07527f3 (crypto/hash: Implement and use new hash API, > > 2024-10-08), we've been seeing a memory leak in two che

Re: [PATCH] hw/nvme: fix handling of over-committed queues

); > > -start_sqs = nvme_cq_full(cq) ? 1 : 0; > cq->head = new_head; > if (!qid && n->dbbuf_enabled) { > stl_le_pci_dma(pci, cq->db_addr, cq->head, > MEMTXATTRS_UNSPECIFIED); > } > - if (start_sqs

[PATCH 18/21] target/microblaze: Explicitly set 2-NaN propagation rule

Set the NaN propagation rule explicitly for the float_status word used in the microblaze target. This is probably not the architecturally correct behaviour, but since this is a no-behaviour-change patch, we leave a TODO note to that effect. Signed-off-by: Peter Maydell --- target/microblaze/cpu

Re: [PATCH 0/2] arm: Add collie and sx functional tests

On 10/25/24 08:25, Jan Lübbe wrote: On Fri, 2024-10-25 at 06:59 -0700, Guenter Roeck wrote: On 10/25/24 02:57, Jan Lübbe wrote: On Fri, 2024-10-25 at 08:55 +0200, Cédric Le Goater wrote: On 10/24/24 19:59, Philippe Mathieu-Daudé wrote: Cc'ing Jan. On 22/10/24 12:04, Guenter Roeck wrote: I

Re: [RFC 14/21] arm/cpu: Add sysreg generation scripts

On Fri, 25 Oct 2024 11:17:33 +0100, Eric Auger wrote: > > Introduce scripts that automate the generation of system register > definitions from a given linux source tree arch/arm64/tools/sysreg. > > Invocation of > ./update-aarch64-sysreg-code.sh $PATH_TO_LINUX_SOURCE_TREE > in scripts directory

[PATCH 07/23] rust/pl011: Use correct masks for IBRD and FBRD

From: Manos Pitsidianakis Port fix from commit cd247eae16ab1b9ce97fd34c000c1b883feeda45 "hw/char/pl011: Use correct masks for IBRD and FBRD" Related issue: Signed-off-by: Manos Pitsidianakis Signed-off-by: Paolo Bonzini Link: https://lore.

[PATCH 13/23] rust: synchronize dependencies between subprojects and Cargo.lock

The next commit will introduce a new build.rs dependency for rust/qemu-api, version_check. Before adding it, ensure that all dependencies are synchronized between the Meson- and cargo-based build systems. Note that it's not clear whether in the long term we'll use Cargo for anything; it seems tha

Re: [PATCH] hw/nvme: fix handling of over-committed queues

On Fri, Oct 25, 2024 at 12:50:45PM +0200, Klaus Jensen wrote: > @@ -1520,9 +1520,16 @@ static void nvme_post_cqes(void *opaque) > nvme_inc_cq_tail(cq); > nvme_sg_unmap(&req->sg); > + > +if (QTAILQ_EMPTY(&sq->req_list) && !nvme_sq_empty(sq)) { > +qemu_bh_schedul

Re: [PATCH 1/4] qom: TYPE_SINGLETON interface

On Fri, Oct 25, 2024, 5:51 a.m. Daniel P. Berrangé wrote: > On Thu, Oct 24, 2024 at 12:56:24PM -0400, Peter Xu wrote: > > Adding significant new functionality to QOM should really come > with a commit message explaining the rationale and the design > choices > Ohh i definitely missed it, my bad.

Re: [PATCH v3 00/23] rust: fix CI + allow older versions of rustc and bindgen

Paolo, you picked up my patches without us first talking about it. This is not how things should work.

Re: [PATCH 1/2] target/i386: fix hang when using slow path for ptw_setl

On 10/24/24 09:25, Richard Henderson wrote: On 10/23/24 23:20, Pierrick Bouvier wrote: When instrumenting memory accesses for plugin, we force memory accesses to use the slow path for mmu. [1] This create a situation where we end up calling ptw_setl_slow. Since this function gets called duri

Re: [PATCH 1/4] qom: TYPE_SINGLETON interface

On Fri, Oct 25, 2024 at 10:51:21AM +0100, Daniel P. Berrangé wrote: > On Thu, Oct 24, 2024 at 12:56:24PM -0400, Peter Xu wrote: > > Adding significant new functionality to QOM should really come > with a commit message explaining the rationale and the design > choices > > > Signed-off-by: Peter X

Re: qcrypto_ivgen mem leak and possible issue?

On Fri, Oct 25, 2024 at 01:06:01PM -0300, Matheus Tavares Bernardino wrote: > Hi, > > Since e3c07527f3 (crypto/hash: Implement and use new hash API, > 2024-10-08), we've been seeing a memory leak in two check-unit tests: > test-crypto-hash and test-crypto-ivgen. Looking a bit further to try and >

Re: [PATCH 03/11] rust/qemu-api-macros: introduce Device proc macro

I disagree with your points, Paolo. A patch review should not be "Fear Uncertainty and Doubt" but point out actual problems with the code. Please do not proceed with this conversation since it's not productive. If this series misses softfreeze because of code problems or by people delaying the rev

Re: [PATCH 1/4] qom: TYPE_SINGLETON interface

On Fri, Oct 25, 2024 at 12:17:02PM -0400, Peter Xu wrote: > On Fri, Oct 25, 2024 at 10:51:21AM +0100, Daniel P. Berrangé wrote: > > > diff --git a/qom/qom-qmp-cmds.c b/qom/qom-qmp-cmds.c > > > index e91a235347..ecc1cf781c 100644 > > > --- a/qom/qom-qmp-cmds.c > > > +++ b/qom/qom-qmp-cmds.c > > > @@

Re: [PATCH 1/4] qom: TYPE_SINGLETON interface

On Fri, Oct 25, 2024 at 12:11:51PM -0300, Philippe Mathieu-Daudé wrote: > On 24/10/24 17:53, Peter Xu wrote: > > On Thu, Oct 24, 2024 at 05:02:19PM -0300, Philippe Mathieu-Daudé wrote: > > > Hi Peter, > > > > Hi, Phil, > > > > Thanks for the quick reviews! > > > > > > > > (Cc'ing Mark) > > > >

[PATCH 23/23] ci: enable rust in the Debian and Ubuntu system build job

We have fixed all incompatibilities with older versions of rustc and bindgen. Enable Rust on Debian to check that the minimum supported version of Rust is indeed 1.63.0, and 0.60.x for bindgen. Signed-off-by: Paolo Bonzini --- .gitlab-ci.d/buildtest.yml | 4 ++-- 1 file changed, 2 insertions(+)

[PATCH 05/23] rust/pl011: add TYPE_PL011_LUMINARY device

From: Manos Pitsidianakis Add a device specialization for the Luminary UART device. This commit adds a DeviceId enum that utilizes the Index trait to return different bytes depending on what device id the UART has (Arm -default- or Luminary) Signed-off-by: Manos Pitsidianakis Signed-off-by: Pa

[PATCH 17/23] rust: clean up detection of the language

Disable the detection code altogether if have_system == false. Signed-off-by: Paolo Bonzini --- meson.build | 42 ++ 1 file changed, 22 insertions(+), 20 deletions(-) diff --git a/meson.build b/meson.build index 69b8367eb3c..d199bcdd824 100644 --- a/meson

Re: [PATCH 1/2] Revert "Remove the unused sh4eb target"

On 10/24/24 03:27, Thomas Huth wrote: This reverts commit 73ceb12960e686b763415f0880cc5171ccce01cf. The "r2d" machine can work in big endian mode, see: https://lore.kernel.org/qemu-devel/d6755445-1060-48a8-82b6-2f392c21f...@landley.net/ So the reasoning for removing sh4eb was wrong. Signed

Re: [PATCH 1/3] vfio/migration: Report only stop-copy size in vfio_state_pending_exact()

On 10/25/24 17:18, Michael Tokarev wrote: 20.10.2024 16:01, Avihai Horon: vfio_state_pending_exact() is used to update migration core how much device data is left for the device migration. Currently, the sum of pre-copy and stop-copy sizes of the VFIO device are reported. The pre-copy size is o

[PATCH 10/23] rust: use std::os::raw instead of core::ffi

core::ffi::c_* types were introduced in Rust 1.64.0. Use the older types in std::os::raw, which are now aliases of the types in core::ffi. There is no need to compile QEMU as no_std, so this is acceptable as long as we support a version of Debian with Rust 1.63.0. Reviewed-by: Zhao Liu Signed-o

[PATCH 09/23] rust: fix cfgs of proc-macro2 for 1.63.0

Replay the configuration that would be computed by build.rs when compiling on a 1.63.0 compiler. Reviewed-by: Junjie Mao Signed-off-by: Paolo Bonzini --- subprojects/packagefiles/proc-macro2-1-rs/meson.build | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/subprojects/pack

[PATCH 20/23] rust: allow older version of bindgen

Cope with the old version that is provided in Debian 12. --size_t-is-usize is needed on bindgen <0.61.0, and it was removed in bindgen 0.65.0, so check for it in meson.build. --merge-extern-blocks was added in 0.61.0. --formatter rustfmt was added in 0.65.0 and is the default, so remove it. Apa

Re: Please put qemu-system-sh4eb back.

On 10/24/24 00:44, Thomas Huth wrote: On 24/10/2024 02.11, Rob Landley wrote: I use it, and ship system images for it:    https://landley.net/bin/mkroot/latest/sh4eb.tgz Oh, that's interesting, I've been told that the r2d machine does not work in big endian mode:  https://lore.kernel.org/

[PATCH 19/23] rust: do not use --generate-cstr

--generate-cstr is a good idea and generally the right thing to do, but it is not available in Debian 12 and Ubuntu 22.04. Work around the absence. Signed-off-by: Paolo Bonzini --- meson.build | 4 +++- rust/hw/char/pl011/src/device.rs | 1 + rust/qemu-api/src/device_cl

qcrypto_ivgen mem leak and possible issue?

Hi, Since e3c07527f3 (crypto/hash: Implement and use new hash API, 2024-10-08), we've been seeing a memory leak in two check-unit tests: test-crypto-hash and test-crypto-ivgen. Looking a bit further to try and plug the leak, I got a bit confused regarding how the result crypto buffer is handled. L

[PATCH 06/23] rust/pl011: remove commented out C code

From: Manos Pitsidianakis This code juxtaposed what should be happening according to the C device model but is not needed now that this has been reviewed (I hope) and its validity checked against what the C device does (I hope, again). No functional change. Signed-off-by: Manos Pitsidianakis S

[PATCH 12/23] rust: silence unknown warnings for the sake of old compilers

Occasionally, we may need to silence warnings and clippy lints that were only introduced in newer Rust compiler versions. However, this would fail when compiling with an older rustc: error: unknown lint: `non_local_definitions` --> rust/qemu-api/rust-qemu-api-tests.p/structured/offset_of.rs:79

[PATCH 16/23] rust: do not use MaybeUninit::zeroed()

MaybeUninit::zeroed() is handy but is not available as a "const" function until Rust 1.75.0. Remove the default implementation of Zeroable::ZERO, and write by hand the definitions for those types that need it. It may be possible to add automatic implementation of the trait, via a procedural macro

  1   2   3   4   >