Re: [PATCH] i386/kvm: Disable hypercall patching quirk by default

> On 22. Jul 2025, at 13:06, Xiaoyao Li wrote: > > On 7/22/2025 6:35 PM, Mohamed Mediouni wrote: >>> On 22. Jul 2025, at 12:27, Xiaoyao Li wrote: >>> >>> On 7/22/2025 5:21 PM, Mathias Krause wrote: >>>> On 22.07.25 05:45, Xiaoyao Li wrote:

Re: [PATCH] i386/kvm: Disable hypercall patching quirk by default

> On 22. Jul 2025, at 12:27, Xiaoyao Li wrote: > > On 7/22/2025 5:21 PM, Mathias Krause wrote: >> On 22.07.25 05:45, Xiaoyao Li wrote: >>> On 6/20/2025 3:42 AM, Mathias Krause wrote: KVM has a weird behaviour when a guest executes VMCALL on an AMD system or VMMCALL on an Intel CPU. B

Re: [PATCH 1/2] target/arm: hvf: add timer frequency note

_vm_create: 2400 […] Sigh. > On 22. Jul 2025, at 07:52, Philippe Mathieu-Daudé wrote: > > Hi Mohamed, > > On 21/7/25 17:29, Mohamed Mediouni wrote: >> On Apple M3 and later, the timer frequency within apps and VM guests are >> different from each other. >

[PATCH 2/2] target/arm: hvf: stubbing reads to LORC_EL1

Linux zeroes LORC_EL1 on boot at EL2, without further interaction with FEAT_LOR afterwards. Stub out LORC_EL1 accesses as FEAT_LOR is a mandatory extension on Armv8.1+. Signed-off-by: Mohamed Mediouni --- target/arm/hvf/hvf.c | 4 1 file changed, 4 insertions(+) diff --git a/target/arm

[PATCH 0/2] target/arm: hvf: add timer freq note and stubbing LORC_EL1 reads

Hopefully will be useful to know for somebody while I keep testing HVF vGIC and nested virt patches. Mohamed Mediouni (2): target/arm: hvf: add timer frequency note target/arm: hvf: stubbing reads to LORC_EL1 target/arm/hvf/hvf.c | 11 +++ 1 file changed, 11 insertions

[PATCH 1/2] target/arm: hvf: add timer frequency note

On Apple M3 and later, the timer frequency within apps and VM guests are different from each other. Note that app binaries compiled with older SDKs continue to retain a non-1 GHz timer frequency on Apple M3/M4. Signed-off-by: Mohamed Mediouni --- target/arm/hvf/hvf.c | 7 +++ 1 file

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

worthwhile. Mohamed Mediouni (1): hw/arm: virt: add GICv2m for the case when ITS is not available hw/arm/virt-acpi-build.c | 4 +++- hw/arm/virt.c| 8 +++- include/hw/arm/virt.h| 2 ++ 3 files changed, 12 insertions(+), 2 deletions(-) -- 2.39.5 (Apple Git-154)

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

On Hypervisor.framework for macOS and WHPX for Windows, the provided environment is a GICv3 without ITS. As such, support a GICv3 w/ GICv2m for that scenario. Signed-off-by: Mohamed Mediouni --- hw/arm/virt-acpi-build.c | 4 +++- hw/arm/virt.c| 8 +++- include/hw/arm/virt.h

Re: [PATCH v2 1/2] hvf: arm: Add permission check in GIC sysreg handlers

> On 21. Jul 2025, at 12:19, Peter Maydell wrote: > > On Mon, 14 Jul 2025 at 21:04, Philippe Mathieu-Daudé > wrote: >> >> On 14/7/25 18:01, Zenghui Yu wrote: >>> Quoting Peter Maydell: >>> >>> " hvf_sysreg_read_cp() and hvf_sysreg_write_cp() do not check the .access >>> field of the ARMC

GICv3 + GICv2m configuration for -M virt

Hello, On arm64 the platform GICs exposed in Hypervisor.framework on macOS and WHPX on Windows* do not provide an ITS but do come with an expectation that a GICv2m will be used for MSIs. Would it be a good idea to shift Qemu over to exposing a GICv3 + GICv2m configuration in those cases by def