Re: [RFC PATCH 0/1] TCTI TCG backend for acceleration on non-JIT AArch64

On 7/22/25 10:42, Joelle van Dyne wrote: The following patch is from work by Katherine Temkin to add a JITless backend for aarch64. The aarch64-tcti target for TCG uses pre-compiled "gadgets" which are snippets of code for every TCG op x all operands and then at runtime will "thread" together the

[PATCH 0/1] Support per-head resolutions with virtio-gpu

In 454f4b0f, we started down the path of supporting separate configurations per display head (e.g., you have 2 heads - one with EDID name "AAA" and the other with EDID name "BBB"). In this change, we add resolution to this configuration surface (e.g., you have 2 heads - one with resolution 111x222

[RFC PATCH 0/1] TCTI TCG backend for acceleration on non-JIT AArch64

The following patch is from work by Katherine Temkin to add a JITless backend for aarch64. The aarch64-tcti target for TCG uses pre-compiled "gadgets" which are snippets of code for every TCG op x all operands and then at runtime will "thread" together the gadgets with jumps after each gadget. This

[PATCH 0/1] hw/arm: virt: add GICv2m for the case when ITS is not available

Client virtualization environments shipping with a GICv3 + GICv2m configuration without support for emulating an ITS makes this more and more necessary... Done in a backwards-compatible way without altering the existing device model for older guests, but wonder if having a separate gicv2m flag is

[PATCH 0/1] hw/s390x: Remediate legacy API call

From: Jared Rossi Remediate the use of a legacy API call introduced by a recent patch. Jared Rossi (1): hw/s390x: Use preferred API call for IPLB chain write hw/s390x/ipl.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) -- 2.49.0

[PATCH 0/1] Sphinx: refactor QAPI indices

RFC quality - what do we think about this style of index vs the one we currently have? John Snow (1): docs/qapi-domain: Improve QAPI indices docs/sphinx/qapi_domain.py | 51 +++--- 1 file changed, 37 insertions(+), 14 deletions(-) -- 2.48.1

[PATCH 0/1] Add RISCV ZALASR Extension

Ping, resending as no comments in over 2 weeks. Roan Richmond (1): Add RISCV ZALASR extension target/riscv/cpu.c | 1 + target/riscv/cpu_cfg.h | 1 + target/riscv/insn32.decode | 10 ++ target/riscv/insn_trans/trans_rvzalas

[PATCH 0/1] Add RISCV ZALASR Extension

Adds the Atomic Load-Acquire and Store-Release Extension (ZALASR). This extension is currently frozen, with no changes expected. The repository for this extension can be found: https://github.com/riscv/riscv-zalasr. Roan Richmond (1): Add RISCV ZALASR extension target/riscv/cpu.c

[PATCH 0/1] Fix racy SEGFAULT upon monitor_cleanup()

From: Andrey Drobyshev There's a race in monitor cleanup code which might result into SEGFAULT. When monitor_cleanup() is launched, qmp_dispatcher_co coroutine pointer is set to NULL (see Paolo's commit 3e6bed61 ("monitor: cleanup detection of qmp_dispatcher_co shutting down")). If after that we

[RFC PATCH 0/1] add fixed file table support

Hi everyone, I am a GSoC QEMU community applicant this year, and I have just completed this contribution task suggested by the project mentors Kevin and Stefan. This task requires registering the file descriptor of a block file that currently uses io_uring as the AIO method to an io_uring instance

[PATCH 0/1] Fix endless translation loop of riscv

Hello! I'm Ziqiao Kong, the maintainer of Unicorn Engine, a fork of QEMU. When I port Unicorn Engine to s390x, I notice there is a bug in the implementation of RISCV MMU. It uses qemu_map_ram_ptr to get a pointer and reads it directly, instead of bswap or address_space_ldl, which causes an endless

Re: [PATCH 0/1] hw/nvme: create parameter to enable/disable cmic on subsystem

On 4/8/25 11:47 PM, Klaus Jensen wrote: On Apr 8 15:56, Alan Adamson wrote: While testing Linux atomic writes with qemu-nvme v10.0.0-rc1, Linux was incorrectly displaying atomic_write_max_bytes # cat /sys/block/nvme0n1/queue/atomic_write_max_bytes 0 # nvme id-ctrl /dev/nvme0n1 | grep awupf aw

Re: [PATCH 0/1] hw/nvme: create parameter to enable/disable cmic on subsystem

On Apr 8 15:56, Alan Adamson wrote: > While testing Linux atomic writes with qemu-nvme v10.0.0-rc1, Linux was > incorrectly displaying atomic_write_max_bytes > # cat /sys/block/nvme0n1/queue/atomic_write_max_bytes > 0 > # nvme id-ctrl /dev/nvme0n1 | grep awupf > awupf : 15 > # > Since AWUPF w

[PATCH 0/1] hw/nvme: create parameter to enable/disable cmic on subsystem

While testing Linux atomic writes with qemu-nvme v10.0.0-rc1, Linux was incorrectly displaying atomic_write_max_bytes # cat /sys/block/nvme0n1/queue/atomic_write_max_bytes 0 # nvme id-ctrl /dev/nvme0n1 | grep awupf awupf : 15 # Since AWUPF was set to 15, it was expected atomic_write_max_bytes

Re: [PATCH 0/1 v2] [RISC-V/RVV] use a single function to probe memory.

On Thu, Mar 13, 2025 at 10:40 PM Paolo Savini wrote: > > Previous version: > > - v1: > https://lore.kernel.org/all/20250221162036.61521-1-paolo.sav...@embecosm.com/ > > Add reviewer information and rebase on top of riscv-to-apply.next branch. > > Cc: Richard Handerson > Cc: Palmer Dabbelt > Cc:

Re: [PATCH 0/1 v4] target/riscv: use tcg ops generation to emulate whole reg rvv loads/stores.

On Fri, Mar 14, 2025 at 1:24 AM Paolo Savini wrote: > > Previous versions: > > - RFC v1: > https://lore.kernel.org/all/20241218170840.1090473-1-paolo.sav...@embecosm.com/ > - RFC v2: > https://lore.kernel.org/all/20241220153834.16302-1-paolo.sav...@embecosm.com/ > - RFC v3: > https://lore.kerne

Re: [PATCH 0/1 v2] [RISCV/RVV] Generate strided vector loads/stores with tcg nodes.

On Thu, Mar 13, 2025 at 1:57 AM Paolo Savini wrote: > > Previous version: > > - PATCH v1: > https://lore.kernel.org/all/20250211182056.412867-1-paolo.sav...@embecosm.com/ > > Follwing the suggestion in the following review by Daniel Barboza: > > https://lore.kernel.org/all/9be2ecc4-fed3-4774-a921

Re: [PATCH 0/1 RFC] FUSE Export Coroutine Integration Cover Letter

On Mon, Mar 24, 2025 at 04:05:09PM +0800, saz97 wrote: > This patch series refactors QEMU's FUSE export module to leverage coroutines > for read/write operations, > addressing concurrency limitations and aligning with QEMU's asynchronous I/O > model. The changes > demonstrate measurable performan

[PATCH 0/1 RFC] FUSE Export Coroutine Integration Cover Letter

This patch series refactors QEMU's FUSE export module to leverage coroutines for read/write operations, addressing concurrency limitations and aligning with QEMU's asynchronous I/O model. The changes demonstrate measurable performance improvements while simplifying resource management. 1. techn

[PATCH 0/1] hw/intc/aspeed: Fix IRQ handler mask check

Dear maintainers, This patch addresses an issue in the ast27x0 interrupt controller where the IRQ handler mask check does not correctly apply the select variable. The fix ensures that the interrupt service routine (ISR) is triggered appropriately for interrupts within the same IRQ group. Please h

Re: [PATCH 0/1 v3] [RISC-V/RVV] optimize the memory probing for vector fault-only-first loads.

On Thu, Mar 13, 2025 at 5:23 AM Paolo Savini wrote: > > Adding reviewer information to the patch and rebasing on top of master. > > Previous versions: > > - v1: > https://lore.kernel.org/all/20250129144435.82451-1-paolo.sav...@embecosm.com/ > - v2: > https://lore.kernel.org/all/20250221155320.59

Re: [PATCH 0/1 RFC] FUSE Export Coroutine Integration Cover Letter

On Sun, Mar 16, 2025 at 01:30:06AM +0800, saz97 wrote: > Signed-off-by: Changzhi Xie > > FUSE Export Coroutine Integration Cover Letter > > This patch series refactors QEMU's FUSE export module to leverage coroutines > for read/write operations, > addressing concurrency limitations and alignin

[PATCH 0/1 RFC] FUSE Export Coroutine Integration Cover Letter

Signed-off-by: Changzhi Xie FUSE Export Coroutine Integration Cover Letter This patch series refactors QEMU's FUSE export module to leverage coroutines for read/write operations, addressing concurrency limitations and aligning with QEMU's asynchronous I/O model. The changes demonstrate measu

[PATCH 0/1 v4] target/riscv: use tcg ops generation to emulate whole reg rvv loads/stores.

Previous versions: - RFC v1: https://lore.kernel.org/all/20241218170840.1090473-1-paolo.sav...@embecosm.com/ - RFC v2: https://lore.kernel.org/all/20241220153834.16302-1-paolo.sav...@embecosm.com/ - RFC v3: https://lore.kernel.org/all/20250122164905.13615-1-paolo.sav...@embecosm.com/ Version v

[PATCH 0/1 v2] [RISC-V/RVV] use a single function to probe memory.

Previous version: - v1: https://lore.kernel.org/all/20250221162036.61521-1-paolo.sav...@embecosm.com/ Add reviewer information and rebase on top of riscv-to-apply.next branch. Cc: Richard Handerson Cc: Palmer Dabbelt Cc: Alistair Francis Cc: Bin Meng Cc: Weiwei Li Cc: Daniel Henrique Barbo

[PATCH 0/1 v3] [RISC-V/RVV] optimize the memory probing for vector fault-only-first loads.

Adding reviewer information to the patch and rebasing on top of master. Previous versions: - v1: https://lore.kernel.org/all/20250129144435.82451-1-paolo.sav...@embecosm.com/ - v2: https://lore.kernel.org/all/20250221155320.59159-1-paolo.sav...@embecosm.com/ Cc: Richard Handerson Cc: Palmer D

[PATCH 0/1 v2] [RISCV/RVV] Generate strided vector loads/stores with tcg nodes.

Previous version: - PATCH v1: https://lore.kernel.org/all/20250211182056.412867-1-paolo.sav...@embecosm.com/ Follwing the suggestion in the following review by Daniel Barboza: https://lore.kernel.org/all/9be2ecc4-fed3-4774-a921-259f36e23...@ventanamicro.com/ we simplified the emulation by tcg

[PATCH 0/1] util/cacheflush: Make first DSB unconditional on aarch64

Hi all, This fixes some TCG TB corruption we would occasionally see on aarch64 hosts in certain situations. Specifically, if the host had CTR_EL0.DIC and CTR_EL0.IDC set, and if the TBs generated were very small, the instructions in the TB would sometimes be garbage. This would mostly result in a

Re: [PATCH 0/1] Adding TPM support for ARM SBSA-Ref machine

On Tue, 25 Feb 2025 at 07:41, Kun Qin wrote: > > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2625 > > This change intends to support an ARM64 server like platform that has TPM > support to unlock more power for sbsa_ref. > > The idea is to add a TPM create routine during sbsa machine i

[PATCH 0/1] Adding TPM support for ARM SBSA-Ref machine

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2625 This change intends to support an ARM64 server like platform that has TPM support to unlock more power for sbsa_ref. The idea is to add a TPM create routine during sbsa machine initialization. The backend can be the same as the rest of

[PATCH 0/1] [RISC-V/RVV] use a single function to probe memory.

This patch originates from the last comment of the following review: https://lore.kernel.org/all/2df9ae98-afb8-4647-be80-12540a1c4...@ventanamicro.com/ We call probe_pages to probe the memory before doing a memory operations or probe_access_flags to do the same while also obtaining probe flags an

[PATCH 0/1 v2] [RISC-V/RVV] optimize the memory probing for vector fault-only-first loads.

This version of the patch addresses the comments from the following review: https://lore.kernel.org/all/2df9ae98-afb8-4647-be80-12540a1c4...@ventanamicro.com/ Previous version: - v1: https://lore.kernel.org/all/20250129144435.82451-1-paolo.sav...@embecosm.com/ The new version: - fixes the "br

[PATCH 0/1] accel/kvm: set coalesced_mmio_ring to NULL after kvm_run is unmapped

Encountered a segfault while exiting because kvm_flush_coalesced_mmio_buffer was getting called after do_kvm_destroy_vcpu unmapped cpu->kvm_run. kvm_state->coalesced_mmio_ring is an offset from cpu->kvm_run so it needs to be set to NULL after kvm_run is unmapped to avoid getting dereferenced by kv

[PATCH 0/1] [RISCV/RVV] Generate strided vector loads/stores with tcg nodes.

The value of the stride of the strided vector loads and stores is known only at execution time and this value determines the location of each vector element to load/store. It is then not possible to improve the performance of the emulation of such instructions by attempting to load/store multiple e

[PATCH 0/1] mem/cxl-type3: Add a default value of sn

The previous default value of sn is UI64_NULL which would cause the cookie of nd_interleave_set be '0' and the "invalid interleave-set -cookie" failure in label validation. As many users maybe not know how to set a unique sn for cxl-type3 device and perhaps be confuesd by the failure of label vali

[PATCH 0/1] CXL CCI Health Information & Alerts Commands implementation

CXL CCI get/set alert config commands implmented as per CXL Specification 3.1 8.2.9.9.3 1)get alert configuration(Opcode 4201h) 2)set alert configuration(Opcode 4202h) The patches are generated against the Johnathan's tree https://gitlab.com/jic23/qemu.git and branch cxl-2024-11-27. Signed-off

Re: [PATCH 0/1] meson: Deprecate 32-bit host systems

On 3/2/25 10:10, Alex Bennée wrote: Peter Maydell writes: On Wed, 29 Jan 2025 at 06:23, Thomas Huth wrote: So unless someone complains immediately with a good reason, I'm also in favor of marking it as deprecated now. If then someone complains during the deprecation period, we still can reco

Re: [PATCH 0/1] meson: Deprecate 32-bit host systems

Peter Maydell writes: > On Wed, 29 Jan 2025 at 06:23, Thomas Huth wrote: >> So unless someone complains immediately with a good reason, I'm also in >> favor of marking it as deprecated now. If then someone complains during the >> deprecation period, we still can reconsider and remove the depreca

[PATCH 0/1] -----BEGIN SSH SIGNATURE-----

fY3jfRbpdO9l1l2wwDZ2l0AAZzaGE1MTIAAABTC3NzaC1lZDI1NTE5 QP6c2B82m4kq6h046Ou/LV6c9I/D/uUtUlivmbvR/lSdCWOiPIYnpK5HPtvhcgVYoQ 8X1k8kKjplch4iy6JnNgU= -END SSH SIGNATURE- julia (1): target/riscv: log guest errors when reserved bits are set in PTEs target/riscv/cpu_helper.

Re: [PATCH 0/1] meson: Deprecate 32-bit host systems

On Fri, Jan 31, 2025 at 06:08:32PM +0100, Paolo Bonzini wrote: > Il ven 31 gen 2025, 17:46 Richard Henderson > ha scritto: > > > On 1/29/25 04:47, Paolo Bonzini wrote: > > > The difference with TCG of course is that TCG is in active development, > > and therefore its > > > 32-bit host support is

Re: [PATCH 0/1] meson: Deprecate 32-bit host systems

Il ven 31 gen 2025, 17:46 Richard Henderson ha scritto: > On 1/29/25 04:47, Paolo Bonzini wrote: > > The difference with TCG of course is that TCG is in active development, > and therefore its > > 32-bit host support is not surviving passively in the same way that a > random device is. > > Still,

Re: [PATCH 0/1] meson: Deprecate 32-bit host systems

On 1/29/25 04:47, Paolo Bonzini wrote: The difference with TCG of course is that TCG is in active development, and therefore its 32-bit host support is not surviving passively in the same way that a random device is. Still, I think we can identify at least three different parts that should be t

Re: [PATCH 0/1] meson: Deprecate 32-bit host systems

On 1/29/25 13:23, Peter Maydell wrote: I'm not really strongly opposed to dropping 32-bit host support, but I don't think a thread on qemu-devel is exactly likely to get the attention of the people who might be using this functionality. (You could argue that functionality without representation a

Re: [PATCH 0/1] meson: Deprecate 32-bit host systems

On Wed, 29 Jan 2025 at 06:23, Thomas Huth wrote: > So unless someone complains immediately with a good reason, I'm also in > favor of marking it as deprecated now. If then someone complains during the > deprecation period, we still can reconsider and remove the deprecation note > again. Well, I m

Re: [PATCH 0/1] meson: Deprecate 32-bit host systems

On 28/01/2025 11.02, Philippe Mathieu-Daudé wrote: On 28/1/25 11:01, Philippe Mathieu-Daudé wrote: On 28/1/25 10:27, Daniel P. Berrangé wrote: On Tue, Jan 28, 2025 at 10:17:33AM +0100, Philippe Mathieu-Daudé wrote: On 28/1/25 10:02, Alex Bennée wrote: Thomas Huth writes: On 28/01/2025 01.4

Re: [PATCH 0/1] meson: Deprecate 32-bit host systems

On 1/28/25 01:27, Daniel P. Berrangé wrote: I'm not sure that's the case here. 32-on-32 is already effectively unmaintained, so we're not suffering in terms of keeping the 32-on-32 code reliable. Correct. As evidence, on i686, the absolutely easiest available 32-bit host, we have the followin

Re: [PATCH 0/1] meson: Deprecate 32-bit host systems

On 28/1/25 11:01, Philippe Mathieu-Daudé wrote: On 28/1/25 10:27, Daniel P. Berrangé wrote: On Tue, Jan 28, 2025 at 10:17:33AM +0100, Philippe Mathieu-Daudé wrote: On 28/1/25 10:02, Alex Bennée wrote: Thomas Huth writes: On 28/01/2025 01.42, Richard Henderson wrote: Time for our biennial a

Re: [PATCH 0/1] meson: Deprecate 32-bit host systems

On 28/1/25 10:27, Daniel P. Berrangé wrote: On Tue, Jan 28, 2025 at 10:17:33AM +0100, Philippe Mathieu-Daudé wrote: On 28/1/25 10:02, Alex Bennée wrote: Thomas Huth writes: On 28/01/2025 01.42, Richard Henderson wrote: Time for our biennial attempt to kill ancient hosts. I've been re-workin

Re: [PATCH 0/1] meson: Deprecate 32-bit host systems

On 28/1/25 10:02, Alex Bennée wrote: Thomas Huth writes: On 28/01/2025 01.42, Richard Henderson wrote: Time for our biennial attempt to kill ancient hosts. I've been re-working the tcg code generator a bit over the holidays. One place that screams for a bit of cleanup is with 64-bit guest add

Re: [PATCH 0/1] meson: Deprecate 32-bit host systems

On Tue, Jan 28, 2025 at 10:17:33AM +0100, Philippe Mathieu-Daudé wrote: > On 28/1/25 10:02, Alex Bennée wrote: > > Thomas Huth writes: > > > > > On 28/01/2025 01.42, Richard Henderson wrote: > > > > Time for our biennial attempt to kill ancient hosts. > > > > I've been re-working the tcg code gen

Re: [PATCH 0/1] meson: Deprecate 32-bit host systems

On Tue, Jan 28, 2025 at 09:02:48AM +, Alex Bennée wrote: > Thomas Huth writes: > > > On 28/01/2025 01.42, Richard Henderson wrote: > >> Time for our biennial attempt to kill ancient hosts. > >> I've been re-working the tcg code generator a bit over the holidays. > >> One place that screams fo

Re: [PATCH 0/1] meson: Deprecate 32-bit host systems

Thomas Huth writes: > On 28/01/2025 01.42, Richard Henderson wrote: >> Time for our biennial attempt to kill ancient hosts. >> I've been re-working the tcg code generator a bit over the holidays. >> One place that screams for a bit of cleanup is with 64-bit guest >> addresses on 32-bit hosts. Of

Re: [PATCH 0/1] meson: Deprecate 32-bit host systems

On 28/01/2025 01.42, Richard Henderson wrote: Time for our biennial attempt to kill ancient hosts. I've been re-working the tcg code generator a bit over the holidays. One place that screams for a bit of cleanup is with 64-bit guest addresses on 32-bit hosts. Of course the best "cleanup" is to

[PATCH 0/1] meson: Deprecate 32-bit host systems

Time for our biennial attempt to kill ancient hosts. I've been re-working the tcg code generator a bit over the holidays. One place that screams for a bit of cleanup is with 64-bit guest addresses on 32-bit hosts. Of course the best "cleanup" is to not have to handle such silliness at all. Two y

[PATCH 0/1] fallocate missing fd_offset

From: William Roche Working on the poisoned memory recovery mechanisms with David Hildenbrand, it appeared that the file hole punching done with the memory discard functions are missing the file offset value fd_offset to correctly modify the right file location. I'm not sure that guest_memfd wou

[PATCH 0/1] s390x: Abort immediately on invalid loadparm

From: Jared Rossi This is a small fix to the IPL behavior in case the user has entered an invalid loadparm. The loadparm is a very specific value, which must be deliberately set by the user. Therefore, if it is not valid, then it is a mistake in the guest configuration. As such, we immediately

[PATCH 0/1] cxl/cxl-host: Support creation of a new CXL Host Bridge

Background == Currently the base CXL support for arm platforms is only on Jonathan's patches[1] which have not yet merged into upstream. Some platform like SBSA-REF can be more like a real machine, thus the support of cxl could be meaningful. However, the pxb-cxl-host realization on this pl

Re: [External] : Re: [RFC PATCH 0/1] ACPI: Fix missing CPU hotplug/hotunplug events with > 255 vCPUs

On Tue, 10 Dec 2024 01:22:24 + Eric Mackay wrote: > On Mon, 9 Dec 2024 15:36:06 +0100 > Igor Mammedov imamm...@redhat.com wrote: > > > On Tue, 3 Dec 2024 16:56:35 -0800 > > Eric Mackay eric.mac...@oracle.com wrote: > > > >> ACPI

Re: [External] : Re: [RFC PATCH 0/1] ACPI: Fix missing CPU hotplug/hotunplug events with > 255 vCPUs

On Mon, 9 Dec 2024 15:36:06 +0100 Igor Mammedov imamm...@redhat.com wrote: > On Tue, 3 Dec 2024 16:56:35 -0800 > Eric Mackay eric.mac...@oracle.com wrote: > >> ACPI hotplug with 255 or less vCPUs can use the legacy CPU hotplug >> interf

Re: [RFC PATCH 0/1] ACPI: Fix missing CPU hotplug/hotunplug events with > 255 vCPUs

On Tue, 3 Dec 2024 16:56:35 -0800 Eric Mackay wrote: > ACPI hotplug with 255 or less vCPUs can use the legacy CPU hotplug interface, > which does > not support hotunplug. If it's available, hotunplug will use the modern CPU > hotplug interface. > This creates a situation where hotplug and hotu

[PATCH 0/1] cxl/cxl-host: Support creation of a new CXL Host Bridge

Background == Currently the base CXL support for arm platforms is only on Jonathan's patches[1] which have not yet merged into upstream. Some platform like SBSA-REF can be more like a real machine, thus the support of cxl could be meaningful. However, the pxb-cxl-host realization on this pl

[RFC PATCH 0/1] ACPI: Fix missing CPU hotplug/hotunplug events with > 255 vCPUs

ACPI hotplug with 255 or less vCPUs can use the legacy CPU hotplug interface, which does not support hotunplug. If it's available, hotunplug will use the modern CPU hotplug interface. This creates a situation where hotplug and hotunplug are using different interfaces, but the end result is still

[PATCH 0/1] Update email addr

For reviewers: note also that I have signed a tag with my GPG key fingerprint 635020F967A7716479EF49E0175C464E541B6D47 that has had this new uid added to it. See https://github.com/quic/qemu/tree/bcain-email-addr-update-oss.qualcomm.com and https://github.com/quic/qemu/releases/tag/bcain-email-ad

[PATCH 0/1] Add cortex-m0+ support

Hello, I have a patch that should allow to support cortex-m0+. I used it in a special arm virtual machine that is still in progress (and not submitted). I think this can be usefull. Matthieu Castet (1): target/arm: Add cortex-m0+ support hw/intc/armv7m_nvic.c| 38

Re: [PATCH 0/1] Insert LibSPDM in QEMU enabling in-tree compilation

On Thu, Oct 17, 2024 at 11:37 PM Ágatha Freitas wrote: > > > > On Thu, Oct 17, 2024 at 7:00 AM Daniel P. Berrangé > wrote: >> >> On Thu, Oct 17, 2024 at 02:00:35PM +1000, Alistair Francis wrote: >> > On Thu, Oct 17, 2024 at 2:35 AM htafr wrote: >> > > >> > > (I) Summary >> > > =

Re: [PATCH 0/1] Insert LibSPDM in QEMU enabling in-tree compilation

On Thu, Oct 17, 2024 at 10:37:21AM -0300, Ágatha Freitas wrote: > On Thu, Oct 17, 2024 at 7:00 AM Daniel P. Berrangé > wrote: > > > On Thu, Oct 17, 2024 at 02:00:35PM +1000, Alistair Francis wrote: > > > On Thu, Oct 17, 2024 at 2:35 AM htafr wrote: > > > > > > > > (I) Summary > > > > > > ===

Re: [PATCH 0/1] Insert LibSPDM in QEMU enabling in-tree compilation

On Thu, Oct 17, 2024 at 7:00 AM Daniel P. Berrangé wrote: > On Thu, Oct 17, 2024 at 02:00:35PM +1000, Alistair Francis wrote: > > On Thu, Oct 17, 2024 at 2:35 AM htafr wrote: > > > > > > (I) Summary > > > > === > > > > > > T

Re: [PATCH 0/1] Insert LibSPDM in QEMU enabling in-tree compilation

On Thu, Oct 17, 2024 at 02:00:35PM +1000, Alistair Francis wrote: > On Thu, Oct 17, 2024 at 2:35 AM htafr wrote: > > > > (I) Summary > > === > > > > This patch is the beginning of the support of the Security Protocol and > > D

Re: [PATCH 0/1] Insert LibSPDM in QEMU enabling in-tree compilation

On Thu, Oct 17, 2024 at 2:35 AM htafr wrote: > > (I) Summary > === > > This patch is the beginning of the support of the Security Protocol and > Data Model (SPDM). There are some known issues (see II), but it's > usable and no

[PATCH 0/1] Insert LibSPDM in QEMU enabling in-tree compilation

(I) Summary === This patch is the beginning of the support of the Security Protocol and Data Model (SPDM). There are some known issues (see II), but it's usable and not many users are going to use this functionality for now,

[Bug Report][RFC PATCH 0/1] block: fix failing assert on paused VM migration

There's a bug (failing assert) which is reproduced during migration of a paused VM. I am able to reproduce it on a stand with 2 nodes and a common NFS share, with VM's disk on that share. root@fedora40-1-vm:~# virsh domblklist alma8-vm Target Source --

Re: [PATCH 0/1] plugins: add API to read guest CPU memory from hwaddr

> > See: > > tests/tcg/i386/system/boot.S > tests/tcg/alpha/system/boot.S > tests/tcg/loongarch64/system/boot.S > tests/tcg/aarch64/system/boot.S > tests/tcg/x86_64/system/boot.S > tests/tcg/arm/system/boot.S > > for what is needed (basically a MMU-enabled flat memory map and some >

Re: [PATCH 0/1] hw/nvme: add atomic write support

On 9/17/24 9:21 AM, alan.adam...@oracle.com wrote: On 9/17/24 12:59 AM, Klaus Jensen wrote: On Aug 20 09:11, Alan Adamson wrote: Since there is work in the Linux NVMe Driver community to add Atomic Write support, it would be desirable to be able to test it with qemu nvme emulation.   This p

Re: [PATCH 0/1] hw/nvme: add atomic write support

On 9/17/24 12:59 AM, Klaus Jensen wrote: On Aug 20 09:11, Alan Adamson wrote: Since there is work in the Linux NVMe Driver community to add Atomic Write support, it would be desirable to be able to test it with qemu nvme emulation. This patch will focus on supporting NVMe controller atomic

Re: [PATCH 0/1] hw/nvme: add atomic write support

On Aug 20 09:11, Alan Adamson wrote: > Since there is work in the Linux NVMe Driver community to add Atomic Write > support, it would be desirable to be able to test it with qemu nvme emulation. > > This patch will focus on supporting NVMe controller atomic write parameters > (AWUN and > AWUPF)

[PATCH 0/1] Keep transaction attribute in address_space_map()

The follow-up transactions may use the data in the attribution, so keep the value of attribution from the function parameter. Fea.Wang (1): softmmu/physmem.c: Keep transaction attribute in address_space_map() system/physmem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.1

Re: [PATCH 0/1] plugins: add API to read guest CPU memory from hwaddr

Rowan Hart writes: > This patch adds a single API function which allows reading from a guest > CPU physical address. > > I don't know of a good way to add a self-contained test for this feature > to tests/tcg/plugins, but I did come up with a small test case to > demonstrate the functionality usi

[RFC PATCH 0/1] MdePkg/IndustryStandard: add definitions for ACPI 6.4 CEDT

RFC because - Less experience and not particularly confident in edk2 area so this might be stupidly broken in a way I've not considered. I am trying to support cxl on Qemu sbsa-ref platform, but it relies on CXL ACPI elements within compiled UEFI flash instead of virt/i386 using qemu-build-Acpi

[PATCH 0/1] plugins: add API to read guest CPU memory from hwaddr

This patch adds a single API function which allows reading from a guest CPU physical address. I don't know of a good way to add a self-contained test for this feature to tests/tcg/plugins, but I did come up with a small test case to demonstrate the functionality using peiyuanix/riscv-os: First, g

[PATCH 0/1] Subject: Support deposit8 in include/qemu/bitops.h

Jason Fan (1): include/qemu/bitops.h: Add deposit8 for uint8_t bit operation include/qemu/bitops.h | 26 ++ 1 file changed, 26 insertions(+) -- 2.46.0.295.g3b9ea8a38a-goog

[PATCH 0/1] hw/nvme: add atomic write support

Since there is work in the Linux NVMe Driver community to add Atomic Write support, it would be desirable to be able to test it with qemu nvme emulation. This patch will focus on supporting NVMe controller atomic write parameters (AWUN and AWUPF) but can be extended to support Namespace paramete

[PATCH 0/1] linux-user patch queue

The following changes since commit c4d062885529a84928ddd260dab419b7d8dd4f90: Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging (2024-08-15 07:41:16 +1000) are available in the Git repository at: https://gitlab.com/rth7680/qemu.git tags/pull-lu-20240815 for you to fet

Re: [PATCH 0/1] module: Prevent crash by resetting local_err in module_load_qom_all()

Queued, thanks. Paolo

[PATCH 0/1] module: Prevent crash by resetting local_err in module_load_qom_all()

After updating QEMU modules previously executed QEMU processes crash on module loading. It happens because error_setg() calls with a not NULL errp argument. There is a discussion - https://issues.redhat.com/browse/RHEL-29848 Alexander Ivanov (1): module: Prevent crash by resetting local_err in

[PATCH 0/1] Fix energy calcultation in RAPL MSR

Hi Paolo, The value reported by the calculation was looking very wrong to me. This should fix it for good. Calculated value appears now way more accurate from what is expected from the feature: with "-smp 4": [...] # modprobe intel_rapl_msr.ko intel_rapl_common: Found RAPL domain package inte

[PATCH 0/1] Brief description of the patch series

The purpose of this patch is customize refresh rate and resolution for the guest VM instead of being limited by the actual resolution of the host. Although it is possible to configure the VM kernel cmdline to set the EDID, such as with drm.edid_firmware=edid/1920x1080.bin, this approach is very

[PATCH 0/1] i386/tcg fix for IRET as used in dotnet runtime

This patch fixes the i386/tcg implementation of the IRET instruction so that IRET can return from user space to user space, as used by the dotnet runtime to switch threads. This fixes https://gitlab.com/qemu-project/qemu/-/issues/249 I debugged this issue 4+ years ago, and wrote this patch then.

Re: [PATCH 0/1] hw/arm/sbsa-ref: switch to 1GHz timer frequency

On Fri, 31 May 2024 at 10:37, Marcin Juszkiewicz wrote: > > Trusted Firmware 2.11 got released, EDK2 202405 got released as well. > Both were built for QEMU CI and proper patch is now in arm.next queue. > > So all requirements to move from legacy 62.5MHz to armv8.6-ready 1GHz > frequency are fulfi

Re: [RFC PATCH 0/1] vhost-user: Add SHMEM_MAP/UNMAP requests

On Wed, Jun 5, 2024 at 1:16 PM Stefan Hajnoczi wrote: > On Wed, Jun 05, 2024 at 09:24:36AM +0200, Albert Esteve wrote: > > On Tue, Jun 4, 2024 at 8:16 PM Stefan Hajnoczi > wrote: > > > > > On Thu, May 30, 2024 at 05:22:22PM +0200, Albert Esteve wrote: > > > > Hi all, > > > > > > > > This is an e

Re: [RFC PATCH 0/1] vhost-user: Add SHMEM_MAP/UNMAP requests

On Wed, Jun 05, 2024 at 09:24:36AM +0200, Albert Esteve wrote: > On Tue, Jun 4, 2024 at 8:16 PM Stefan Hajnoczi wrote: > > > On Thu, May 30, 2024 at 05:22:22PM +0200, Albert Esteve wrote: > > > Hi all, > > > > > > This is an early attempt to have backends > > > support dynamic fd mapping into sha

Re: [RFC PATCH 0/1] vhost-user: Add SHMEM_MAP/UNMAP requests

On Tue, Jun 4, 2024 at 8:16 PM Stefan Hajnoczi wrote: > On Thu, May 30, 2024 at 05:22:22PM +0200, Albert Esteve wrote: > > Hi all, > > > > This is an early attempt to have backends > > support dynamic fd mapping into shared > > memory regions. As such, there are a few > > things that need settlin

Re: [RFC PATCH 0/1] vhost-user: Add SHMEM_MAP/UNMAP requests

On Thu, May 30, 2024 at 05:22:22PM +0200, Albert Esteve wrote: > Hi all, > > This is an early attempt to have backends > support dynamic fd mapping into shared > memory regions. As such, there are a few > things that need settling, so I wanted to > post this first to have some early feedback. > >

[PATCH 0/1] hw/arm/sbsa-ref: switch to 1GHz timer frequency

Trusted Firmware 2.11 got released, EDK2 202405 got released as well. Both were built for QEMU CI and proper patch is now in arm.next queue. So all requirements to move from legacy 62.5MHz to armv8.6-ready 1GHz frequency are fulfiled. Marcin Juszkiewicz (1): hw/arm/sbsa-ref: switch to 1GHz time

[RFC PATCH 0/1] vhost-user: Add SHMEM_MAP/UNMAP requests

Hi all, This is an early attempt to have backends support dynamic fd mapping into shared memory regions. As such, there are a few things that need settling, so I wanted to post this first to have some early feedback. The usecase for this is, e.g., to support vhost-user-gpu RESOURCE_BLOB operation

Re: [RFC PATCH 0/1] pci: allocate a PCI ID for RISC-V IOMMU

On 5/10/24 07:47, Frank Chang wrote: Hi Daniel, Daniel Henrique Barboza 於 2024年5月8日 週三 下午8:42寫道： On 5/7/24 12:44, Peter Maydell wrote: On Fri, 3 May 2024 at 13:43, Daniel Henrique Barboza wrote: Hi, In this RFC I want to check with Gerd and others if it's ok to add a PCI id for the

[PATCH 0/1] riscv, gdbstub.c: fix reg_width in ricsv_gen_dynamic_vector_feature()

Hi, Commit 33a24910ae ("target/riscv: Use GDBFeature for dynamic XML") changed 'reg_width' for vector regs, a change that I believe to be unintended, and we're unable to print vector regs in GDB ATM. The following is a gdb output of a simple program running with qemu-riscv64 when trying to print

Re: [RFC PATCH 0/1] pci: allocate a PCI ID for RISC-V IOMMU

Hi Daniel, Daniel Henrique Barboza 於 2024年5月8日 週三 下午8:42寫道： > > > > On 5/7/24 12:44, Peter Maydell wrote: > > On Fri, 3 May 2024 at 13:43, Daniel Henrique Barboza > > wrote: > >> > >> Hi, > >> > >> In this RFC I want to check with Gerd and others if it's ok to add a PCI > >> id for the RISC-V IO

Re: [RFC PATCH 0/1] pci: allocate a PCI ID for RISC-V IOMMU

On 5/7/24 12:44, Peter Maydell wrote: On Fri, 3 May 2024 at 13:43, Daniel Henrique Barboza wrote: Hi, In this RFC I want to check with Gerd and others if it's ok to add a PCI id for the RISC-V IOMMU device. It's currently under review in [1]. The idea is to fold this patch into the RISC-V

Re: [RFC PATCH 0/1] pci: allocate a PCI ID for RISC-V IOMMU

On 5/7/24 12:53, Gerd Hoffmann wrote: On Tue, May 07, 2024 at 11:37:05PM GMT, Frank Chang wrote: Hi Daniel, Daniel Henrique Barboza 於 2024年5月3日 週五 下午8:43寫道： Hi, In this RFC I want to check with Gerd and others if it's ok to add a PCI id for the RISC-V IOMMU device. It's currently under r

Re: [RFC PATCH 0/1] pci: allocate a PCI ID for RISC-V IOMMU

On 5/7/24 12:37, Frank Chang wrote: Hi Daniel, Daniel Henrique Barboza 於 2024年5月3日 週五 下午8:43寫道： Hi, In this RFC I want to check with Gerd and others if it's ok to add a PCI id for the RISC-V IOMMU device. It's currently under review in [1]. The Is the link [1] missing? Ooops. Here's t

  1   2   3   4   5   6   7   8   9   10   >