Re: [RFC PATCH 1/5] qtest/pci: Enforce balanced iomap/unmap

Nicholas Piggin writes: > Add assertions to ensure a BAR is not mapped twice, and only > previously mapped BARs are unmapped. This can help catch some > bugs. > > Signed-off-by: Nicholas Piggin Reviewed-by: Fabiano Rosas

Re: [PATCH v9 01/16] ui & main loop: Redesign of system-specific main thread event handling

On Mon, 11 Nov 2024 at 05:45, Akihiko Odaki wrote: > > On 2024/11/11 6:55, Phil Dennis-Jordan wrote: > > macOS's Cocoa event handling must be done on the initial (main) thread > > of the process. Furthermore, if library or application code uses > > libdispatch, the main dispatch queue must be hand

Re: [PATCH] linux-user/strace: show TID instead of PID

On 10/23/24 16:47, J. Neuschäfer wrote: This aligns with strace, and is very useful when tracing multi-threaded programs. The result is the same in single-threaded programs. See also "-D log.%d -d tid -strace" which will split the output into per-tid files. gettid() requires the _GNU_SOURCE

[PATCH v2] hw/i386/elfboot: allocate "header" in heap

In x86_load_linux(), we were using a stack-allocated array as data for fw_cfg_add_bytes(). Since the latter just takes a reference to the pointer instead of copying the data, it can happen that the contents have been overridden by the time the guest attempts to access them. Instead of using the st

[PATCH for-9.2] accel/tcg: Fix user-only probe_access_internal plugin check

The acc_flag check for write should have been against PAGE_WRITE_ORG, not PAGE_WRITE. But it is better to combine two acc_flag checks to a single check against access_type. This matches the system code in cputlb.c. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2647 Signed-off-by: Richa

[PATCH v2 4/8] convert code to object_new_dynamic() where appropriate

In cases where object_new() is not being passed a static, const string, the caller cannot be sure what type they are instantiating. There is a risk that instantiation could fail, if it is an abstract type. Convert such cases over to use object_new_dynamic() such that they are forced to expect fail

[PATCH v2 0/8] Require error handling for dynamically created objects

NB, this series is targetting 10.0, NOT for 9.2 freeze. With code like Object *obj = object_new(TYPE_BLAH) the caller can be pretty confident that they will successfully create an object instance of TYPE_BLAH. They know exactly what type has been requested, so it passing an abstract type for

Re: [PATCH 7/7] target/riscv: Enable updates for pointer masking variables and thus enable pointer masking extension

On 11/8/24 3:01 AM, baturo.ale...@gmail.com wrote: From: Alexey Baturo Signed-off-by: Alexey Baturo --- target/riscv/cpu.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c index 4e80dcd2e6..13b2c56a72 100644 --- a/target/riscv/cpu.c +++ b/

Re: [PATCH v2 3/5] target/riscv: Support hstatus[HUKTE] bit when svukte extension is enabled

On 11/8/24 5:52 AM, Fea.Wang wrote: Svukte extension add HUKTE bit, bit[24] in hstatus CSR. The written value will be masked when the svukte extension is not enabled. When hstatus[HUKTE] bit is set, HLV/HLVX/HSV work in the U-mode should do svukte check. Signed-off-by: Fea.Wang Reviewed-by:

Re: [PATCH v2 2/5] target/riscv: Support senvcfg[UKTE] bit when svukte extension is enabled

On 11/8/24 5:52 AM, Fea.Wang wrote: Svukte extension add UKTE bit, bit[8] in senvcfg CSR. The bit will be supported when the svukte extension is enabled. When senvcfg[UKTE] bit is set, the memory access from U-mode should do the svukte check only except HLV/HLVX/HSV H-mode instructions which

Re: [PATCH v2 1/5] target/riscv: Add svukte extension capability variable

On 11/8/24 5:52 AM, Fea.Wang wrote: Refer to the draft of svukte extension from: https://github.com/riscv/riscv-isa-manual/pull/1564 Svukte provides a means to make user-mode accesses to supervisor memory raise page faults in constant time, mitigating attacks that attempt to discover the supe

Re: [PATCH 31/36] next-cube: add rtc-cmd-reset named gpio to reset the rtc state machine

On 09/11/2024 08:24, Thomas Huth wrote: Am Wed, 23 Oct 2024 09:58:47 +0100 schrieb Mark Cave-Ayland : This allows us to decouple the next-pc and next-rtc devices from each other in next_scr2_rtc_update(). Signed-off-by: Mark Cave-Ayland --- hw/m68k/next-cube.c | 23 +++

Re: [PATCH 27/36] next-cube: QOMify NeXTRTC

On 09/11/2024 08:14, Thomas Huth wrote: Am Wed, 23 Oct 2024 09:58:43 +0100 schrieb Mark Cave-Ayland : This is to allow the RTC functionality to be maintained within its own separate device. Signed-off-by: Mark Cave-Ayland --- hw/m68k/next-cube.c | 66 ---

Re: [PATCH 33/36] next-cube: move next_rtc_cmd_is_write() and next_rtc_data_in_irq() functions

On 09/11/2024 08:25, Thomas Huth wrote: Am Wed, 23 Oct 2024 09:58:49 +0100 schrieb Mark Cave-Ayland : Move these functions in next-cube.c so that they are with the rest of the next-rtc functions. Signed-off-by: Mark Cave-Ayland --- hw/m68k/next-cube.c | 172 ++--

Re: [PATCH v3 1/3] hw/riscv: Support to load DTB after 3GB memory on 64-bit system.

On 11/8/24 4:04 AM, Jim Shu wrote: Larger initrd image will overlap the DTB at 3GB address. Since 64-bit system doesn't have 32-bit addressable issue, we just load DTB to the end of dram in 64-bit system. Signed-off-by: Jim Shu --- hw/riscv/boot.c| 8 ++-- hw/riscv/microch

[PATCH 2/2] target/mips: Convert nanoMIPS LSA opcode to decodetree

From: Philippe Mathieu-Daudé Simply call the generic gen_lsa() helper, taking care to substract 1 to the shift field. Signed-off-by: Philippe Mathieu-Daudé Signed-off-by: Philippe Mathieu-Daudé --- target/mips/tcg/nanomips32.decode| 8 target/mips/tcg/nanomips_translate.c

[PATCH 0/2] target/mips: Convert nanoMIPS LSA opcode to decodetree

Yet another 2 patches extracted from an old branch I'm rebasing. Trivial decodetree conversion of LSA, however this introduce the basis to convert nanoMIPS opcodes. Philippe Mathieu-Daudé (2): target/mips: Introduce decode tree bindings for nanoMIPS ISA target/mips: Convert nanoMIPS LSA opcode

[PATCH 1/2] target/mips: Introduce decode tree bindings for nanoMIPS ISA

From: Philippe Mathieu-Daudé Introduce the nanoMIPS decodetree configs for the 16-bit and 32-bit instructions. Signed-off-by: Philippe Mathieu-Daudé Signed-off-by: Philippe Mathieu-Daudé --- target/mips/tcg/translate.h | 2 ++ target/mips/tcg/nanomips16.decode| 8 ++

[PATCH v2 2/2] hw/display: check frame buffer can hold blob

Coverity reports (CID 1564769, 1564770) that we potentially overflow by doing some 32x32 multiplies for something that ends up in a 64 bit value. Fix this by first using stride for all lines and casting input to uint64_t to ensure a 64 bit multiply is used. Signed-off-by: Alex Bennée Cc: Dmitry O

[PATCH v2 1/2] hw/display: factor out the scanout blob to fb conversion

There are two identical sequences of a code doing the same thing that raise warnings with Coverity. Before fixing those issues lets factor out the common code into a helper function we can share. Signed-off-by: Alex Bennée Cc: Dmitry Osipenko --- v2 - fix compile of virtio-gpu-virgl - tweak

[PATCH v2 0/2] virtio-gpu: coverity fixes

v2, Fixes after Dimitry's review. Alex. Alex Bennée (2): hw/display: factor out the scanout blob to fb conversion hw/display: check frame buffer can hold blob include/hw/virtio/virtio-gpu.h | 15 + hw/display/virtio-gpu-virgl.c | 22 + hw/display/virtio-gpu.c|

Re: [PATCH 1/6] bitops.h: add deposit16 function

Reviewed-by: Glenn Miles On Thu, 2024-11-07 at 19:54 +, Titus Rwantare wrote: > Makes it more explicit that 16 bit values are being used > > Signed-off-by: Titus Rwantare > --- > include/qemu/bitops.h | 26 ++ > 1 file changed, 26 insertions(+) > > diff --git a/inc

Re: [PATCH v3 3/3] hw/riscv: Add the checking if DTB overlaps to kernel or initrd

On 11/8/24 4:04 AM, Jim Shu wrote: DTB is placed to the end of memory, so we will check if the start address of DTB overlaps to the address of kernel/initrd. Signed-off-by: Jim Shu --- Reviewed-by: Daniel Henrique Barboza hw/riscv/boot.c | 25 - inclu

Re: [PATCH v3 2/3] hw/riscv: Add a new struct RISCVBootInfo

On 11/8/24 4:04 AM, Jim Shu wrote: Add a new struct RISCVBootInfo to sync boot information between multiple boot functions. Signed-off-by: Jim Shu --- hw/riscv/boot.c| 65 +- hw/riscv/microchip_pfsoc.c | 12 +++--- hw/riscv/opentita

[PATCH 0/3] target/mips: Convert Octeon LX instructions to decodetree

Hi, Few old patches lingering on an old branch I'm trying to rebase... Extract gen_lx() and call it via decodetree. Trivial IMHO. Philippe Mathieu-Daudé (3): target/mips: Extract gen_base_index_addr() helper target/mips: Extract generic gen_lx() helper target/mips: Convert Octeon LX instru

[PATCH 2/3] target/mips: Extract generic gen_lx() helper

Extract gen_lx() from gen_mips_lx(); inline the Octeon check in decode_opc_special3_legacy(). Signed-off-by: Philippe Mathieu-Daudé --- target/mips/tcg/translate.h | 1 + target/mips/tcg/translate.c | 55 + 2 files changed, 20 insertions(+), 36 deletions(-)

[PATCH 1/3] target/mips: Extract gen_base_index_addr() helper

Factor out gen_base_index_addr() which is used twice but we'll use it more. Signed-off-by: Philippe Mathieu-Daudé --- target/mips/tcg/translate.h | 1 + target/mips/tcg/translate.c | 27 +-- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/target/mips/tcg

[PATCH 3/3] target/mips: Convert Octeon LX instructions to decodetree

Use Octeon decodetree to call gen_lx() for the LX instructions. Signed-off-by: Philippe Mathieu-Daudé --- target/mips/tcg/octeon.decode | 8 target/mips/tcg/octeon_translate.c | 12 target/mips/tcg/translate.c| 4 +--- 3 files changed, 21 insertions(+), 3 del

Re: [PATCH qemu] hw/cxl: Check for zero length features in cmd_features_set_feature()

On Fri, Nov 08, 2024 at 05:58:14PM +, Jonathan Cameron wrote: > Zero length data for features doesn't make any sense so exclude that case > early. This fixes the undefined behavior reported by coverity for a zero > length memcpy(). > > Resolves CID 1564900 and 1564901 > > Reported-by: Peter M

[PATCH] hw/net/rocker/rocker_of_dpa.c: Remove superfluous error check

of_dpa_cmd_add_acl_ip() is called from a single place, and despite the fact that it always returns ROCKER_OK, its return value is still checked by the caller. Change of_dpa_cmd_add_acl_ip() to return void and remove the superfluous check from of_dpa_cmd_add_acl(). Resolves: https://gitlab.com/qemu-

Re: [RFC 18/21] arm/cpu: Introduce a customizable kvm host cpu model

On Mon, Nov 04 2024, Eric Auger wrote: > Hi Daniel, > > On 10/28/24 18:04, Daniel P. Berrangé wrote: >> On Mon, Oct 28, 2024 at 04:48:18PM +, Peter Maydell wrote: >>> On Mon, 28 Oct 2024 at 16:35, Daniel P. Berrangé >>> wrote: On Mon, Oct 28, 2024 at 04:16:31PM +, Peter Maydell wro

Re: [RFC PATCH 4/5] qtest/xhci: Add controller and device setup and ring tests

Nicholas Piggin writes: > Add tests which init the host controller registers to the point > where command and event rings, irqs are operational. Enumerate > ports and set up an attached device context that enables device > transfer ring to be set up and tested. > > This test does a bunch of thing

Undelivered Mail Returned to Sender

This is the mail system at host blackfin.pond.sub.org. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete

Re: [PATCH] block: Fix leak in send_qmp_error_event

Philippe Mathieu-Daudé writes: > On 11/11/24 14:52, Fabiano Rosas wrote: >> ASAN detected a leak when running the ahci-test >> /ahci/io/dma/lba28/retry: >> >> Direct leak of 35 byte(s) in 1 object(s) allocated from: >> #0 in malloc >> #1 in __vasprintf_internal >> #2 in vasprintf

Re: [sdl-qemu] [PATCH] tests/qtest: fix heap-use-after-free

On 11.11.2024 16:35, Дмитрий Фролов wrote: > > > On 11.11.2024 15:51, Prasad Pandit wrote: >> On Mon, 11 Nov 2024 at 17:41, Дмитрий Фролов wrote: >>> Above loop dereferences the pointer env, which is pointing to >>> the memory area, which is not allowed to read. >> * Not allowed to read environmen

Re: [PATCH] linux-user/strace: show TID instead of PID

On 11/11/24 06:59, Richard Henderson wrote: On 10/23/24 16:47, J. Neuschäfer wrote: This aligns with strace, and is very useful when tracing multi-threaded programs. The result is the same in single-threaded programs. See also "-D log.%d -d tid -strace" which will split the output into per-tid

[PATCH v2 6/8] qom: introduce qdev_new_dynamic()

qdev_new() has a failure scenario where it will assert() if given an abstract type. Callers which are creating qdevs based on user input, or unknown/untrusted type names, must manually check the result of qdev_class_is_abstract() before calling qdev_new() to propagate an Error, instead of asserting

[PATCH v2 7/8] convert code to qdev_new_dynamic() where appropriate

In cases where qdev_new() is not being passed a static, const string, the caller cannot be sure what type they are instantiating. There is a risk that instantiation could fail, if it is an abstract type. Convert such cases over to use qdev_new_dynamic() such that they are forced to expect failure.

[PATCH v2 2/8] qom: allow failure of object_new_with_class

Since object_new_with_class() accepts a non-const parameter for the class, callers should be prepared for failures from unexpected input. Add an Error parameter for this and make callers check. If the caller does not already have an Error parameter, it is satisfactory to use &error_abort if the cla

[PATCH v2 1/8] qom: refactor checking abstract property when creating instances

Push an Error object into object_initialize_with_type, so that reporting of attempts to create an abstract type is handled at the lowest level. Signed-off-by: Daniel P. Berrangé --- qom/object.c | 30 -- 1 file changed, 20 insertions(+), 10 deletions(-) diff --git a/

[PATCH v2 3/8] qom: introduce object_new_dynamic()

object_new() has a failure scenario where it will assert() if given an abstract type. Callers which are creating objects based on user input, or unknown/untrusted type names, must manually check the result of object_class_is_abstract() before calling object_new() to propagate an Error, instead of a

[PATCH v2 8/8] hw: enforce use of static, const string with qdev_new()

Since qdev_new() will assert(), it should only be used in scenarios where the caller knows exactly what type it is asking to be created, and can thus be confident in avoiding abstract types. Enforce this by using a macro wrapper which types to paste "" to the type name. This will generate a compil

[PATCH v2 5/8] qom: enforce use of static, const string with object_new()

Since object_new() will assert(), it should only be used in scenarios where the caller knows exactly what type it is asking to be created, and can thus be confident in avoiding abstract types. Enforce this by using a macro wrapper which types to paste "" to the type name. This will generate a comp

Re: [PATCH v8 01/15] ui & main loop: Redesign of system-specific main thread event handling

On Mon, 11 Nov 2024, Phil Dennis-Jordan wrote: On Mon, 11 Nov 2024 at 13:41, BALATON Zoltan wrote: On Mon, 11 Nov 2024, Phil Dennis-Jordan wrote: On Mon, 11 Nov 2024 at 10:08, Daniel P. Berrangé wrote: On Sun, Nov 10, 2024 at 08:08:16AM +0100, Phil Dennis-Jordan wrote: On Sun 10. Nov 2024

Re: [PATCH v1 0/4] Initialize nr_cores and nr_threads early and related clearup

On 08.11.24 08:06, Xiaoyao Li wrote: This series is extracted from TDX QEMU v6[1] series per Paolo's request. It is originally motivated by x86 TDX to track CPUID_HT in env->features[] which requires nr_cores and nr_cores being initialized earlier than in "and nr_threads" qemu_init_vcpu().

[PATCH] docs/system/bootindex: Make it clear that s390x can also boot from virtio-net

Let's make it clear that s390x can also boot from virtio-net, to avoid that people think that s390x can only boot from disk devices. Reported-by: Boris Fiuczynski Signed-off-by: Thomas Huth --- docs/system/bootindex.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/sy

KVM/QEMU community call 12/11/2024 agenda items

Hi, The KVM/QEMU community call is at: https://meet.jit.si/kvmcallmeeting @ 12/11/2024 14:00 UTC So far I have the following agenda items: - Rust next steps and merging strategy (Paolo/Manos) - Rust as a device API (Mark) Anything else? -- Alex Bennée Virtualisation Tech Lead @ Linaro

Re: [PATCH] tests/qtest: fix heap-use-after-free

On Mon, 11 Nov 2024 at 14:37, Dmitry Frolov wrote: > "int main(int argc, char **argv, char** envp)" is non-standart > Microsoft`s extention of the C language and it`s not portable. > In my particular case (Debian 13, clang-16) this raises wild-pointer > dereference with ASAN message "heap-use-afte

Re: [PATCH] hw/i386/elfboot: allocate "header" in heap

On 8/11/24 23:03, s...@redhat.com wrote: From: Sergio Lopez In x86_load_linux(), we were using a stack-allocated array as data for fw_cfg_add_bytes(). Since the latter just takes a reference to the pointer instead of copying the data, it can happen that the contents have been overridden by the

Re: [PATCH v3 17/17] tests/functional: Add microblaze cross-endianness tests

On 11/11/24 07:57, Thomas Huth wrote: On 08/11/2024 16.43, Philippe Mathieu-Daudé wrote: Copy/paste the current tests, but call the opposite endianness machines, testing: - petalogix-s3adsp1800-le machine (little-endian CPU) on the    qemu-system-microblaze binary (big-endian) - petalogix-s3adsp

Re: [PATCH v3 15/17] hw/microblaze: Support various endianness for s3adsp1800 machines

On 11/11/24 07:56, Thomas Huth wrote: On 08/11/2024 16.43, Philippe Mathieu-Daudé wrote: Introduce an abstract machine parent class which defines the 'little_endian' property. Duplicate the current machine, which endian is tied to the binary endianness, to one big endian and a little endian mach

Re: [RFC PATCH v3 04/17] hw/net/xilinx_ethlite: Simplify by having configurable endianness

On 8/11/24 16:05, Paolo Bonzini wrote: On 11/8/24 16:43, Philippe Mathieu-Daudé wrote: The Xilinx 'ethlite' device was added in commit b43848a100 ("xilinx: Add ethlite emulation"), being only built back then for a big-endian MicroBlaze target (see commit 72b675caac "microblaze: Hook into the bui

[RFC v5 0/1] target/riscv: rvv: reduce the overhead for simple RISC-V vector.

The version 5 of the patch set splits the patches into independent submissions so to simplify the review process. Previous versions: - v1: https://lore.kernel.org/all/20240717153040.11073-1-paolo.sav...@embecosm.com/ - v2: https://lore.kernel.org/all/20241002135708.99146-1-paolo.sav...@embecosm.

[RFC v5 1/1] target/riscv: rvv: reduce the overhead for simple RISC-V vector unit-stride loads and stores

This patch improves the performance of the emulation of the RVV unit-stride loads and stores in the following cases: - when the data being loaded/stored per iteration amounts to 8 bytes or less. - when the vector length is 16 bytes (VLEN=128) and there's no grouping of the vector registers (LMUL

[PATCH] pc-bios/s390-ccw: Re-initialize receive queue index before each boot attempt

Now that we can boot from multiple boot devices, we have to make sure to reinitialize static variables like rx_last_idx to avoid that they contain garbage data during the second boot attempt (which can lead to crashes when the code tries to access the wrong ring data). Signed-off-by: Thomas Huth

Re: [PATCH v8 01/15] ui & main loop: Redesign of system-specific main thread event handling

On Mon, 11 Nov 2024 at 13:41, BALATON Zoltan wrote: > On Mon, 11 Nov 2024, Phil Dennis-Jordan wrote: > > On Mon, 11 Nov 2024 at 10:08, Daniel P. Berrangé > > wrote: > > > >> On Sun, Nov 10, 2024 at 08:08:16AM +0100, Phil Dennis-Jordan wrote: > >>> On Sun 10. Nov 2024 at 08:01, Akihiko Odaki > >

Re: [PATCH v1] vhost: fail device start if iotlb update fails

Hello Jason, On Mon, 11 Nov 2024 at 07:08, Jason Wang wrote: > > While starting a vhost device, updating iotlb entries > > via 'vhost_device_iotlb_miss' may return an error. > > > > qemu-kvm: vhost_device_iotlb_miss: > > 700871,700871: Fail to update device iotlb > > Actually, such updating

Re: [PATCH v8 01/15] ui & main loop: Redesign of system-specific main thread event handling

On Mon, 11 Nov 2024 at 10:08, Daniel P. Berrangé wrote: > On Sun, Nov 10, 2024 at 08:08:16AM +0100, Phil Dennis-Jordan wrote: > > On Sun 10. Nov 2024 at 08:01, Akihiko Odaki > > wrote: > > > > > On 2024/11/08 23:46, Phil Dennis-Jordan wrote: > > > > macOS's Cocoa event handling must be done on t

[PATCH] vhost_net: fix assertion triggered by batch of host notifiers processing

From: zuoboqun When the backend of vhost_net restarts during the vm is running, vhost_net is stopped and started. The virtio_device_grab_ioeventfd() fucntion in vhost_net_enable_notifiers() will result in a call to virtio_bus_set_host_notifier()(assign=false). And now virtio_device_grab_ioeventf

Re: [PATCH v1 2/2] migration: Do not perform RAMBlock dirty sync during the first iteration

On 09.11.24 05:59, Hyman Huang wrote: The first iteration's RAMBlock dirty sync can be omitted because QEMU always initializes the RAMBlock's bmap to all 1s by default. Signed-off-by: Hyman Huang --- migration/cpu-throttle.c | 2 +- migration/ram.c | 11 --- 2 files change

[PATCH] tests/qtest: fix heap-use-after-free

"int main(int argc, char **argv, char** envp)" is non-standart Microsoft`s extention of the C language and it`s not portable. In my particular case (Debian 13, clang-16) this raises wild-pointer dereference with ASAN message "heap-use-after-free". Signed-off-by: Dmitry Frolov --- tests/qtest/qos

RE: [PATCH v1 2/2] migration: Do not perform RAMBlock dirty sync during the first iteration

On Saturday, November 9, 2024 1:00 PM, Hyman Huang wrote: > The first iteration's RAMBlock dirty sync can be omitted because QEMU > always initializes the RAMBlock's bmap to all 1s by default. > > Signed-off-by: Hyman Huang > --- > migration/cpu-throttle.c | 2 +- > migration/ram.c | 1

Re: [PATCH v8 01/15] ui & main loop: Redesign of system-specific main thread event handling

On Sun, Nov 10, 2024 at 08:08:16AM +0100, Phil Dennis-Jordan wrote: > On Sun 10. Nov 2024 at 08:01, Akihiko Odaki > wrote: > > > On 2024/11/08 23:46, Phil Dennis-Jordan wrote: > > > macOS's Cocoa event handling must be done on the initial (main) thread > > > of the process. Furthermore, if librar

Re: test harness hang running functional test

On 07/11/2024 17.09, Peter Maydell wrote: I was trying to track down why one of the functional tests was hanging, so I tried running it directly: UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1 QEMU_TEST_QEMU_BINARY=build/clang/qemu-system-loongarch64 PYTHONPATH=./build/clang/pyvenv:./python time

Re: [PATCH v1 2/2] migration: Do not perform RAMBlock dirty sync during the first iteration

On Mon, Nov 11, 2024 at 6:42 PM David Hildenbrand wrote: > On 11.11.24 11:08, Yong Huang wrote: > > > > > > On Mon, Nov 11, 2024 at 5:27 PM David Hildenbrand > > wrote: > > > > On 09.11.24 05:59, Hyman Huang wrote: > > > The first iteration's RAMBlock dirty sync

Re: [PATCH] hw/i386/elfboot: allocate "header" in heap

"Michael S. Tsirkin" writes: > On Sat, Nov 09, 2024 at 12:03:14AM +0100, s...@redhat.com wrote: >> From: Sergio Lopez >> >> In x86_load_linux(), we were using a stack-allocated array as data for >> fw_cfg_add_bytes(). Since the latter just takes a reference to the >> pointer instead of copying t

Re: [PATCH v3 15/17] hw/microblaze: Support various endianness for s3adsp1800 machines

On 11/11/2024 12.59, Philippe Mathieu-Daudé wrote: On 11/11/24 07:56, Thomas Huth wrote: On 08/11/2024 16.43, Philippe Mathieu-Daudé wrote: Introduce an abstract machine parent class which defines the 'little_endian' property. Duplicate the current machine, which endian is tied to the binary en

[PATCH] pci: ensure valid link status bits for downstream ports

PCI hotplug for downstream endpoints on arm fails because Linux' PCIe hotplug driver doesn't like the QEMU provided LNKSTA: pcieport :08:01.0: pciehp: Slot(2): Card present pcieport :08:01.0: pciehp: Slot(2): Link Up pcieport :08:01.0: pciehp: Slot(2): Cannot train link: status 0

Re: [PATCH v8 01/15] ui & main loop: Redesign of system-specific main thread event handling

On Mon, 11 Nov 2024, Phil Dennis-Jordan wrote: On Mon, 11 Nov 2024 at 10:08, Daniel P. Berrangé wrote: On Sun, Nov 10, 2024 at 08:08:16AM +0100, Phil Dennis-Jordan wrote: On Sun 10. Nov 2024 at 08:01, Akihiko Odaki wrote: On 2024/11/08 23:46, Phil Dennis-Jordan wrote: macOS's Cocoa event

Re: [PATCH] pci: ensure valid link status bits for downstream ports

On Mon, 11 Nov 2024, Sebastian Ott wrote: PCI hotplug for downstream endpoints on arm fails because Linux' PCIe hotplug driver doesn't like the QEMU provided LNKSTA: pcieport :08:01.0: pciehp: Slot(2): Card present pcieport :08:01.0: pciehp: Slot(2): Link Up pcieport :08:01.0: pci

Re: [PATCH] tests/qtest: fix heap-use-after-free

On Mon, 11 Nov 2024 at 17:41, Дмитрий Фролов wrote: > Above loop dereferences the pointer env, which is pointing to > the memory area, which is not allowed to read. * Not allowed to read environment variables? Is it because Debian/clang does not support the '**envp' parameter? Is '**envp' set to

Re: [PATCH v1 2/2] migration: Do not perform RAMBlock dirty sync during the first iteration

On 11.11.24 11:08, Yong Huang wrote: On Mon, Nov 11, 2024 at 5:27 PM David Hildenbrand > wrote: On 09.11.24 05:59, Hyman Huang wrote: > The first iteration's RAMBlock dirty sync can be omitted because QEMU > always initializes the RAMBlock's bmap to all

Re: [PATCH] docs/system/bootindex: Make it clear that s390x can also boot from virtio-net

On Mon, 11 Nov 2024 at 16:25, Thomas Huth wrote: > Let's make it clear that s390x can also boot from virtio-net, to avoid > that people think that s390x can only boot from disk devices. > > Reported-by: Boris Fiuczynski > Signed-off-by: Thomas Huth > --- > docs/system/bootindex.rst | 2 +- > 1

Re: [PATCH v1 2/2] migration: Do not perform RAMBlock dirty sync during the first iteration

On Mon, Nov 11, 2024 at 6:42 PM David Hildenbrand wrote: > On 11.11.24 11:08, Yong Huang wrote: > > > > > > On Mon, Nov 11, 2024 at 5:27 PM David Hildenbrand > > wrote: > > > > On 09.11.24 05:59, Hyman Huang wrote: > > > The first iteration's RAMBlock dirty sync

Re: [PATCH v5 00/19] s390x: Add Full Boot Order Support

On 08/11/2024 15.37, Thomas Huth wrote: ... And in case you're interested (it's maybe not so important since it's rather unlikely that the users will do this), there is another issue when trying to boot from multiple network devices where the first one has a DHCP server but no bootfile: qemu-

Re: [PATCH] tests/qtest: fix heap-use-after-free

On 11.11.2024 14:47, Prasad Pandit wrote: On Mon, 11 Nov 2024 at 14:37, Dmitry Frolov wrote: "int main(int argc, char **argv, char** envp)" is non-standart Microsoft`s extention of the C language and it`s not portable. In my particular case (Debian 13, clang-16) this raises wild-pointer dere

Re: [PATCH] docs/system/bootindex: Make it clear that s390x can also boot from virtio-net

On 11/11/24 11:55, Thomas Huth wrote: Let's make it clear that s390x can also boot from virtio-net, to avoid that people think that s390x can only boot from disk devices. Reported-by: Boris Fiuczynski Signed-off-by: Thomas Huth --- docs/system/bootindex.rst | 2 +- 1 file changed, 1 inserti

Re: [PATCH] tests/qtest: fix heap-use-after-free

On 11.11.2024 15:51, Prasad Pandit wrote: On Mon, 11 Nov 2024 at 17:41, Дмитрий Фролов wrote: Above loop dereferences the pointer env, which is pointing to the memory area, which is not allowed to read. * Not allowed to read environment variables? Is it because Debian/clang does not support

Re: [PATCH] pc-bios/s390-ccw: Re-initialize receive queue index before each boot attempt

On 11/11/24 8:11 AM, Thomas Huth wrote: Now that we can boot from multiple boot devices, we have to make sure to reinitialize static variables like rx_last_idx to avoid that they contain garbage data during the second boot attempt (which can lead to crashes when the code tries to access the wr

[PATCH v5 01/20] intel_iommu: Use the latest fault reasons defined by spec

From: Yu Zhang Spec revision 3.0 or above defines more detailed fault reasons for scalable mode. So introduce them into emulation code, see spec section 7.1.2 for details. Note spec revision has no relation with VERSION register, Guest kernel should not use that register to judge what features a

[PATCH v5 03/20] intel_iommu: Add a placeholder variable for scalable modern mode

Add an new element scalable_mode in IntelIOMMUState to mark scalable modern mode, this element will be exposed as an intel_iommu property finally. For now, it's only a placehholder and used for address width compatibility check and block host device passthrough until nesting is supported. Signed-

[PATCH v5 11/20] intel_iommu: Process PASID-based iotlb invalidation

PASID-based iotlb (piotlb) is used during walking Intel VT-d stage-1 page table. This emulates the stage-1 page table iotlb invalidation requested by a PASID-based IOTLB Invalidate Descriptor (P_IOTLB). Signed-off-by: Yi Liu Signed-off-by: Zhenzhong Duan Reviewed-by: Clément Mathieu--Drif Acked

[PATCH v5 00/20] intel_iommu: Enable stage-1 translation for emulated device

Hi, Per Jason Wang's suggestion, iommufd nesting series[1] is split into "Enable stage-1 translation for emulated device" series and "Enable stage-1 translation for passthrough device" series. This series enables stage-1 translation support for emulated device in intel iommu which we called "mode

[PATCH v5 14/20] intel_iommu: piotlb invalidation should notify unmap

This is used by some emulated devices which caches address translation result. When piotlb invalidation issued in guest, those caches should be refreshed. There is already a similar implementation in iotlb invalidation. So update vtd_iotlb_page_invalidate_notify() to make it work also for piotlb i

[PATCH v5 12/20] intel_iommu: Add an internal API to find an address space with PASID

From: Clément Mathieu--Drif This will be used to implement the device IOTLB invalidation Signed-off-by: Clément Mathieu--Drif Signed-off-by: Zhenzhong Duan Acked-by: Jason Wang Reviewed-by: Yi Liu --- hw/i386/intel_iommu.c | 38 +++--- 1 file changed, 23 inse

[PATCH v5 15/20] tests/acpi: q35: allow DMAR acpi table changes

Signed-off-by: Zhenzhong Duan --- tests/qtest/bios-tables-test-allowed-diff.h | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/qtest/bios-tables-test-allowed-diff.h b/tests/qtest/bios-tables-test-allowed-diff.h index dfb8523c8b..46f80be9ca 100644 --- a/tests/qtest/bios-tables-test-allow

[PATCH v5 02/20] intel_iommu: Make pasid entry type check accurate

When guest configures Nested Translation(011b) or First-stage Translation only (001b), type check passed unaccurately. Fails the type check in those cases as their simulation isn't supported yet. Fixes: fb43cf739e1 ("intel_iommu: scalable mode emulation") Suggested-by: Yi Liu Signed-off-by: Zhen

[PATCH v5 05/20] intel_iommu: Rename slpte to pte

From: Yi Liu Because we will support both FST(a.k.a, FLT) and SST(a.k.a, SLT) translation, rename variable and functions from slpte to pte whenever possible. But some are SST only, they are renamed with sl_ prefix. Signed-off-by: Yi Liu Co-developed-by: Clément Mathieu--Drif Signed-off-by: Cl

[PATCH v5 18/20] intel_iommu: Introduce a property x-flts for scalable modern mode

Intel VT-d 3.0 introduces scalable mode, and it has a bunch of capabilities related to scalable mode translation, thus there are multiple combinations. This vIOMMU implementation wants to simplify it with a new property "x-flts". When enabled in scalable mode, first stage translation also known as

[PATCH v5 07/20] intel_iommu: Check if the input address is canonical

From: Clément Mathieu--Drif First stage translation must fail if the address to translate is not canonical. Signed-off-by: Clément Mathieu--Drif Signed-off-by: Zhenzhong Duan Acked-by: Jason Wang Reviewed-by: Yi Liu --- hw/i386/intel_iommu_internal.h | 1 + hw/i386/intel_iommu.c |

[PATCH v5 08/20] intel_iommu: Check stage-1 translation result with interrupt range

Per VT-d spec 4.1 section 3.15, "Untranslated requests and translation requests that result in an address in the interrupt range will be blocked with condition code LGN.4 or SGN.8." This applies to both stage-1 and stage-2 IOMMU page table, move the check from vtd_iova_to_slpte() to vtd_do_iommu_t

[PATCH v5 13/20] intel_iommu: Add support for PASID-based device IOTLB invalidation

From: Clément Mathieu--Drif Signed-off-by: Clément Mathieu--Drif Signed-off-by: Zhenzhong Duan --- hw/i386/intel_iommu_internal.h | 11 hw/i386/intel_iommu.c | 50 ++ 2 files changed, 61 insertions(+) diff --git a/hw/i386/intel_iommu_internal.

[PATCH v5 10/20] intel_iommu: Flush stage-1 cache in iotlb invalidation

According to spec, Page-Selective-within-Domain Invalidation (11b): 1. IOTLB entries caching second-stage mappings (PGTT=010b) or pass-through (PGTT=100b) mappings associated with the specified domain-id and the input-address range are invalidated. 2. IOTLB entries caching first-stage (PGTT=001b)

[PATCH v5 06/20] intel_iommu: Implement stage-1 translation

From: Yi Liu This adds stage-1 page table walking to support stage-1 only translation in scalable modern mode. Signed-off-by: Yi Liu Co-developed-by: Clément Mathieu--Drif Signed-off-by: Clément Mathieu--Drif Signed-off-by: Yi Sun Signed-off-by: Zhenzhong Duan Acked-by: Jason Wang --- hw/

[PATCH v5 04/20] intel_iommu: Flush stage-2 cache in PASID-selective PASID-based iotlb invalidation

Per VT-d spec 4.1, 6.5.2.4, "Table 21. PASID-based-IOTLB Invalidation", PADID-selective PASID-based iotlb invalidation will flush stage-2 iotlb entries with matching domain id and pasid. With scalable modern mode introduced, guest could send PASID-selective PASID-based iotlb invalidation to flush

[PATCH v5 09/20] intel_iommu: Set accessed and dirty bits during stage-1 translation

From: Clément Mathieu--Drif Signed-off-by: Clément Mathieu--Drif Signed-off-by: Zhenzhong Duan Reviewed-by: Yi Liu Acked-by: Jason Wang --- hw/i386/intel_iommu_internal.h | 3 +++ hw/i386/intel_iommu.c | 25 - 2 files changed, 27 insertions(+), 1 deletion(-)

[PATCH v5 17/20] tests/acpi: q35: Update host address width in DMAR

Differences: @@ -1,39 +1,39 @@ /* * Intel ACPI Component Architecture * AML/ASL+ Disassembler version 20200925 (64-bit version) * Copyright (c) 2000 - 2020 Intel Corporation * - * Disassembly of tests/data/acpi/x86/q35/DMAR.dmar, Mon Nov 11 15:31:18 2024 + * Disassembly of /tmp/aml-SPJ4W2

[PATCH v5 20/20] tests/qtest: Add intel-iommu test

Add the framework to test the intel-iommu device. Currently only tested cap/ecap bits correctness in scalable modern mode. Also tested cap/ecap bits consistency before and after system reset. Signed-off-by: Zhenzhong Duan Acked-by: Thomas Huth Reviewed-by: Clément Mathieu--Drif Acked-by: Jason

[PATCH v5 19/20] intel_iommu: Introduce a property to control FS1GP cap bit setting

This gives user flexibility to turn off FS1GP for debug purpose. It is also useful for future nesting feature. When host IOMMU doesn't support FS1GP but vIOMMU does, nested page table on host side works after turning FS1GP off in vIOMMU. This property has no effect when vIOMMU isn't in scalable m

[PATCH v5 16/20] intel_iommu: Set default aw_bits to 48 starting from QEMU 9.2

According to VTD spec, stage-1 page table could support 4-level and 5-level paging. However, 5-level paging translation emulation is unsupported yet. That means the only supported value for aw_bits is 48. So default aw_bits to 48 in scalable modern mode. For legacy and scalable legacy modes, 48 i

  1   2   >