[PATCH v3 0/6] whpx: arm: set of small fixes for QEMU 11.0

[PATCH v3 0/6] whpx: arm: set of small fixes for QEMU 11.0

[Mohamed Mediouni]

Localised fixes for QEMU 11.0:

- fixes for -cpu host, including an ID_AA64MMFR2_EL1/ID_AA64MMFR3_EL1 mixup
- add EC_DATAABORT assert for WHvRunVpExitReasonGpaIntercept/UnmappedGpa

This one doesn't functionally change anything today, but is good to have and is a single-line change.

- fix Hyper-V enlightenments

AccessVpRegs turns out to be necessary too. Linux doesn't check for its presence and panics in an Hyper-V arm64
configuration without it exposed.

Fixing a mistake in not following the QEMU code style and having had AccessHypercallRegs included twice at the
same time. Also add some more privileges because it looks like guests don't check for presence of each one
systematically...

- SME support shipped in Hyper-V now

So remove a code comment. Another one-liner.

Mohamed Mediouni (5):
  whpx: arm: fix -cpu host
  whpx: arm: add EC_DATAABORT assert for
    WHvRunVpExitReasonGpaIntercept/UnmappedGpa
  whpx: arm: enable more enlightements
  whpx: arm: remove comment bit that is no longer accurate
  target/arm: cpu: alter error message for host CPU type

Osama Abdelkader (1):
  whpx: arm: fix ID_AA64MMFR3_EL1 host feature register index

 hw/arm/virt.c              |  2 +-
 target/arm/cpu.c           |  4 ++--
 target/arm/whpx/whpx-all.c | 11 +++++++----
 3 files changed, 10 insertions(+), 7 deletions(-)

-- 
2.50.1 (Apple Git-155)

[PATCH v3 1/6] whpx: arm: fix -cpu host

[Mohamed Mediouni]

"hw/arm/virt: Register valid CPU types dynamically" went under my radar, so fix this for WHPX.

Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 hw/arm/virt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index bced9f67f4..af3f03ced3 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -3477,7 +3477,7 @@ static GPtrArray *virt_get_valid_cpu_types(const MachineState *ms)
     if (target_aarch64()) {
         g_ptr_array_add(vct, g_strdup(ARM_CPU_TYPE_NAME("cortex-a53")));
         g_ptr_array_add(vct, g_strdup(ARM_CPU_TYPE_NAME("cortex-a57")));
-        if (kvm_enabled() || hvf_enabled()) {
+        if (kvm_enabled() || hvf_enabled() || whpx_enabled()) {
             g_ptr_array_add(vct, g_strdup(ARM_CPU_TYPE_NAME("host")));
         }
     }
-- 
2.50.1 (Apple Git-155)

[PATCH v3 2/6] whpx: arm: add EC_DATAABORT assert for WHvRunVpExitReasonGpaIntercept/UnmappedGpa

[Mohamed Mediouni]

If we get anything else from Hyper-V there's a problem, so enforce this.

Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
Suggested-by: Alex Bennée <alex.bennee@linaro.org>
---
 target/arm/whpx/whpx-all.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/arm/whpx/whpx-all.c b/target/arm/whpx/whpx-all.c
index 513551bec1..3df60a950d 100644
--- a/target/arm/whpx/whpx-all.c
+++ b/target/arm/whpx/whpx-all.c
@@ -439,6 +439,7 @@ int whpx_vcpu_run(CPUState *cpu)
         switch (vcpu->exit_ctx.ExitReason) {
         case WHvRunVpExitReasonGpaIntercept:
         case WHvRunVpExitReasonUnmappedGpa:
+            assert(syn_get_ec(vcpu->exit_ctx.MemoryAccess.Syndrome) == EC_DATAABORT);
             advance_pc = true;
 
             if (vcpu->exit_ctx.MemoryAccess.Syndrome & BIT(8)) {
-- 
2.50.1 (Apple Git-155)

[PATCH v3 3/6] whpx: arm: enable more enlightements

[Mohamed Mediouni]

Linux uses AccessVpRegs without checking availability and panics if it's not there. Expose it unconditionally.

Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
---
 target/arm/whpx/whpx-all.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/target/arm/whpx/whpx-all.c b/target/arm/whpx/whpx-all.c
index 3df60a950d..9e5bc03a21 100644
--- a/target/arm/whpx/whpx-all.c
+++ b/target/arm/whpx/whpx-all.c
@@ -832,6 +832,7 @@ int whpx_accel_init(AccelState *as, MachineState *ms)
     UINT32 whpx_cap_size;
     WHV_PARTITION_PROPERTY prop;
     WHV_CAPABILITY_FEATURES features;
+    WHV_SYNTHETIC_PROCESSOR_FEATURES_BANKS synthetic_features;
     MachineClass *mc = MACHINE_GET_CLASS(ms);
     int pa_range = 0;
 
@@ -942,7 +943,6 @@ int whpx_accel_init(AccelState *as, MachineState *ms)
     }
 
     /* Enable synthetic processor features */
-    WHV_SYNTHETIC_PROCESSOR_FEATURES_BANKS synthetic_features;
     memset(&synthetic_features, 0, sizeof(WHV_SYNTHETIC_PROCESSOR_FEATURES_BANKS));
     synthetic_features.BanksCount = 1;
 
@@ -953,13 +953,15 @@ int whpx_accel_init(AccelState *as, MachineState *ms)
     synthetic_features.Bank0.AccessPartitionReferenceTsc = 1;
     synthetic_features.Bank0.AccessHypercallRegs = 1;
     synthetic_features.Bank0.AccessVpIndex = 1;
-    synthetic_features.Bank0.AccessHypercallRegs = 1;
     synthetic_features.Bank0.TbFlushHypercalls = 1;
     synthetic_features.Bank0.AccessSynicRegs = 1;
     synthetic_features.Bank0.AccessSyntheticTimerRegs = 1;
     synthetic_features.Bank0.AccessIntrCtrlRegs = 1;
     synthetic_features.Bank0.SyntheticClusterIpi = 1;
     synthetic_features.Bank0.DirectSyntheticTimers = 1;
+    synthetic_features.Bank0.FastHypercallOutput = 1;
+    synthetic_features.Bank0.AccessVpRegs = 1;
+    synthetic_features.Bank0.SyncContext = 1;
 
     /*
      * On ARM64, have enlightenments off by default
-- 
2.50.1 (Apple Git-155)

[PATCH v3 4/6] whpx: arm: remove comment bit that is no longer accurate

[Mohamed Mediouni]

As of Windows 11 version 26H1, SME support shipped. However the MIT-licensed headers aren't updated yet.

Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
---
 target/arm/whpx/whpx-all.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/arm/whpx/whpx-all.c b/target/arm/whpx/whpx-all.c
index 9e5bc03a21..8aa24f2adc 100644
--- a/target/arm/whpx/whpx-all.c
+++ b/target/arm/whpx/whpx-all.c
@@ -717,7 +717,7 @@ static bool whpx_arm_get_host_cpu_features(ARMHostCPUFeatures *ahcf)
      * Work needed for SVE support:
      * - SVE state save/restore
      * - any potentially needed VL management
-     * Also disable SME at the same time. (not currently supported by Hyper-V)
+     * Also disable SME at the same time.
      */
     SET_IDREG(&ahcf->isar, ID_AA64PFR0,
               GET_IDREG(&ahcf->isar, ID_AA64PFR0) & ~R_ID_AA64PFR0_SVE_MASK);
-- 
2.50.1 (Apple Git-155)

[PATCH v3 5/6] target/arm: cpu: alter error message for host CPU type

[Mohamed Mediouni]

Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 target/arm/cpu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 7e3e84b4bb..e73d7eb4fc 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1629,8 +1629,8 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp)
      * this is the first point where we can report it.
      */
     if (cpu->host_cpu_probe_failed) {
-        if (!kvm_enabled() && !hvf_enabled()) {
-            error_setg(errp, "The 'host' CPU type can only be used with KVM or HVF");
+        if (!kvm_enabled() && !hvf_enabled() && !whpx_enabled()) {
+            error_setg(errp, "The 'host' CPU type can only be used with KVM, HVF or WHPX");
         } else {
             error_setg(errp, "Failed to retrieve host CPU features");
         }
-- 
2.50.1 (Apple Git-155)

[PATCH v3 6/6] whpx: arm: fix ID_AA64MMFR3_EL1 host feature register index

[Mohamed Mediouni]

From: Osama Abdelkader <osama.abdelkader@gmail.com>

IdAa64Mmfr3El1 was stored in idregs[ID_AA64MMFR2_EL1_IDX], overwriting
MMFR2 and leaving MMFR3 never set. Use ID_AA64MMFR3_EL1_IDX so the host
MMFR3 value is stored in the correct slot.

Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
Reviewed-by: Mohamed Mediouni <mohamed@unpredictable.fr>
---
 target/arm/whpx/whpx-all.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/arm/whpx/whpx-all.c b/target/arm/whpx/whpx-all.c
index 8aa24f2adc..bbf0f6be96 100644
--- a/target/arm/whpx/whpx-all.c
+++ b/target/arm/whpx/whpx-all.c
@@ -684,7 +684,7 @@ static bool whpx_arm_get_host_cpu_features(ARMHostCPUFeatures *ahcf)
         { WHvArm64RegisterIdAa64Mmfr0El1, &ahcf->isar.idregs[ID_AA64MMFR0_EL1_IDX] },
         { WHvArm64RegisterIdAa64Mmfr1El1, &ahcf->isar.idregs[ID_AA64MMFR1_EL1_IDX] },
         { WHvArm64RegisterIdAa64Mmfr2El1, &ahcf->isar.idregs[ID_AA64MMFR2_EL1_IDX] },
-        { WHvArm64RegisterIdAa64Mmfr3El1, &ahcf->isar.idregs[ID_AA64MMFR2_EL1_IDX] }
+        { WHvArm64RegisterIdAa64Mmfr3El1, &ahcf->isar.idregs[ID_AA64MMFR3_EL1_IDX] }
     };
 
     int i;
-- 
2.50.1 (Apple Git-155)

Re: [PATCH v3 6/6] whpx: arm: fix ID_AA64MMFR3_EL1 host feature register index

[Philippe Mathieu-Daudé]

On 14/3/26 23:15, Mohamed Mediouni wrote:
> From: Osama Abdelkader <osama.abdelkader@gmail.com>
> 
> IdAa64Mmfr3El1 was stored in idregs[ID_AA64MMFR2_EL1_IDX], overwriting
> MMFR2 and leaving MMFR3 never set. Use ID_AA64MMFR3_EL1_IDX so the host
> MMFR3 value is stored in the correct slot.
> 
> Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
> Reviewed-by: Mohamed Mediouni <mohamed@unpredictable.fr>
> ---
>   target/arm/whpx/whpx-all.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/arm/whpx/whpx-all.c b/target/arm/whpx/whpx-all.c
> index 8aa24f2adc..bbf0f6be96 100644
> --- a/target/arm/whpx/whpx-all.c
> +++ b/target/arm/whpx/whpx-all.c
> @@ -684,7 +684,7 @@ static bool whpx_arm_get_host_cpu_features(ARMHostCPUFeatures *ahcf)
>           { WHvArm64RegisterIdAa64Mmfr0El1, &ahcf->isar.idregs[ID_AA64MMFR0_EL1_IDX] },
>           { WHvArm64RegisterIdAa64Mmfr1El1, &ahcf->isar.idregs[ID_AA64MMFR1_EL1_IDX] },
>           { WHvArm64RegisterIdAa64Mmfr2El1, &ahcf->isar.idregs[ID_AA64MMFR2_EL1_IDX] },
> -        { WHvArm64RegisterIdAa64Mmfr3El1, &ahcf->isar.idregs[ID_AA64MMFR2_EL1_IDX] }
> +        { WHvArm64RegisterIdAa64Mmfr3El1, &ahcf->isar.idregs[ID_AA64MMFR3_EL1_IDX] }
>       };
>   
>       int i;

Re: [PATCH v3 6/6] whpx: arm: fix ID_AA64MMFR3_EL1 host feature register index

[Philippe Mathieu-Daudé]

On 14/3/26 23:15, Mohamed Mediouni wrote:
> From: Osama Abdelkader <osama.abdelkader@gmail.com>
> 
> IdAa64Mmfr3El1 was stored in idregs[ID_AA64MMFR2_EL1_IDX], overwriting
> MMFR2 and leaving MMFR3 never set. Use ID_AA64MMFR3_EL1_IDX so the host
> MMFR3 value is stored in the correct slot.
> 

Fixes: f7fa2b88084 ("whpx: arm64: implement -cpu host")

> Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
> Reviewed-by: Mohamed Mediouni <mohamed@unpredictable.fr>
> ---
>   target/arm/whpx/whpx-all.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

Re: [PATCH v3 1/6] whpx: arm: fix -cpu host

[Stefan Weil via qemu development]

Am 14.03.26 um 23:15 schrieb Mohamed Mediouni:
> "hw/arm/virt: Register valid CPU types dynamically" went under my radar, so fix this for WHPX.
> 
> Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> ---
>   hw/arm/virt.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index bced9f67f4..af3f03ced3 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -3477,7 +3477,7 @@ static GPtrArray *virt_get_valid_cpu_types(const MachineState *ms)
>       if (target_aarch64()) {
>           g_ptr_array_add(vct, g_strdup(ARM_CPU_TYPE_NAME("cortex-a53")));
>           g_ptr_array_add(vct, g_strdup(ARM_CPU_TYPE_NAME("cortex-a57")));
> -        if (kvm_enabled() || hvf_enabled()) {
> +        if (kvm_enabled() || hvf_enabled() || whpx_enabled()) {
>               g_ptr_array_add(vct, g_strdup(ARM_CPU_TYPE_NAME("host")));
>           }
>       }

Reviewed-by: Stefan Weil <sw@weilnetz.de>

Re: [PATCH v3 3/6] whpx: arm: enable more enlightements

[Peter Maydell]

On Sat, 14 Mar 2026 at 22:15, Mohamed Mediouni <mohamed@unpredictable.fr> wrote:
>
> Linux uses AccessVpRegs without checking availability and panics if it's not there. Expose it unconditionally.

The commit message subject says we're enabling enlightenments...

> @@ -953,13 +953,15 @@ int whpx_accel_init(AccelState *as, MachineState *ms)
>      synthetic_features.Bank0.AccessPartitionReferenceTsc = 1;
>      synthetic_features.Bank0.AccessHypercallRegs = 1;
>      synthetic_features.Bank0.AccessVpIndex = 1;
> -    synthetic_features.Bank0.AccessHypercallRegs = 1;

...but the code change seems to be removing one as well as
adding the three new ones. Intentional?

>      synthetic_features.Bank0.TbFlushHypercalls = 1;
>      synthetic_features.Bank0.AccessSynicRegs = 1;
>      synthetic_features.Bank0.AccessSyntheticTimerRegs = 1;
>      synthetic_features.Bank0.AccessIntrCtrlRegs = 1;
>      synthetic_features.Bank0.SyntheticClusterIpi = 1;
>      synthetic_features.Bank0.DirectSyntheticTimers = 1;
> +    synthetic_features.Bank0.FastHypercallOutput = 1;
> +    synthetic_features.Bank0.AccessVpRegs = 1;
> +    synthetic_features.Bank0.SyncContext = 1;
>
>      /*
>       * On ARM64, have enlightenments off by default

I've taken this series into target-arm.next for the moment --
I can either drop this patch or else fix it up depending on
what the right thing is.

PS: for commit messages, could you wrap the body text at
the usual 70-ish columns, please?

thanks
-- PMM

Re: [PATCH v3 3/6] whpx: arm: enable more enlightements

[Mohamed Mediouni]

> On 19. Mar 2026, at 19:13, Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> On Sat, 14 Mar 2026 at 22:15, Mohamed Mediouni <mohamed@unpredictable.fr> wrote:
>> 
>> Linux uses AccessVpRegs without checking availability and panics if it's not there. Expose it unconditionally.
> 
> The commit message subject says we're enabling enlightenments...
> 
>> @@ -953,13 +953,15 @@ int whpx_accel_init(AccelState *as, MachineState *ms)
>>     synthetic_features.Bank0.AccessPartitionReferenceTsc = 1;
>>     synthetic_features.Bank0.AccessHypercallRegs = 1;
>>     synthetic_features.Bank0.AccessVpIndex = 1;
>> -    synthetic_features.Bank0.AccessHypercallRegs = 1;
> 
> ...but the code change seems to be removing one as well as
> adding the three new ones. Intentional?
Hello,

The AccessHypercallRegs bit was set twice - with the first one being two 
lines earlier - removed a spurious one of the two.

> 
>>     synthetic_features.Bank0.TbFlushHypercalls = 1;
>>     synthetic_features.Bank0.AccessSynicRegs = 1;
>>     synthetic_features.Bank0.AccessSyntheticTimerRegs = 1;
>>     synthetic_features.Bank0.AccessIntrCtrlRegs = 1;
>>     synthetic_features.Bank0.SyntheticClusterIpi = 1;
>>     synthetic_features.Bank0.DirectSyntheticTimers = 1;
>> +    synthetic_features.Bank0.FastHypercallOutput = 1;
>> +    synthetic_features.Bank0.AccessVpRegs = 1;
>> +    synthetic_features.Bank0.SyncContext = 1;
>> 
>>     /*
>>      * On ARM64, have enlightenments off by default
> 
> I've taken this series into target-arm.next for the moment --
> I can either drop this patch or else fix it up depending on
> what the right thing is.
> 
> PS: for commit messages, could you wrap the body text at
> the usual 70-ish columns, please?
Will add some tooling to catch those earlier instead of trying to manually wrap…
(and inevitably failing some of the time…)
> 
> thanks
> -- PMM

Re: [PATCH v3 3/6] whpx: arm: enable more enlightements

[Peter Maydell]

On Thu, 19 Mar 2026 at 18:50, Mohamed Mediouni <mohamed@unpredictable.fr> wrote:
>
>
> > On 19. Mar 2026, at 19:13, Peter Maydell <peter.maydell@linaro.org> wrote:
> >
> > On Sat, 14 Mar 2026 at 22:15, Mohamed Mediouni <mohamed@unpredictable.fr> wrote:
> >>
> >> Linux uses AccessVpRegs without checking availability and panics if it's not there. Expose it unconditionally.
> >
> > The commit message subject says we're enabling enlightenments...
> >
> >> @@ -953,13 +953,15 @@ int whpx_accel_init(AccelState *as, MachineState *ms)
> >>     synthetic_features.Bank0.AccessPartitionReferenceTsc = 1;
> >>     synthetic_features.Bank0.AccessHypercallRegs = 1;
> >>     synthetic_features.Bank0.AccessVpIndex = 1;
> >> -    synthetic_features.Bank0.AccessHypercallRegs = 1;
> >
> > ...but the code change seems to be removing one as well as
> > adding the three new ones. Intentional?
> Hello,
>
> The AccessHypercallRegs bit was set twice - with the first one being two
> lines earlier - removed a spurious one of the two.

Ah, right. How about this for a commit message ?


    whpx: arm: enable more enlightenments

    Unconditionally enable some more enlightenments for whpx. In
    particular, linux uses AccessVpRegs without checking availability and
    panics if it's not there, so it's important to expose it.

    We also had a duplicate line where we set AccessHypercallRegs = 1
    twice; remove the duplicate.


If you have more rationale/info about the other two we're enabling,
that would also be nice to include.

thanks
-- PMM

Re: [PATCH v3 3/6] whpx: arm: enable more enlightements

[Mohamed Mediouni]

> On 20. Mar 2026, at 10:17, Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> On Thu, 19 Mar 2026 at 18:50, Mohamed Mediouni <mohamed@unpredictable.fr> wrote:
>> 
>> 
>>> On 19. Mar 2026, at 19:13, Peter Maydell <peter.maydell@linaro.org> wrote:
>>> 
>>> On Sat, 14 Mar 2026 at 22:15, Mohamed Mediouni <mohamed@unpredictable.fr> wrote:
>>>> 
>>>> Linux uses AccessVpRegs without checking availability and panics if it's not there. Expose it unconditionally.
>>> 
>>> The commit message subject says we're enabling enlightenments...
>>> 
>>>> @@ -953,13 +953,15 @@ int whpx_accel_init(AccelState *as, MachineState *ms)
>>>>    synthetic_features.Bank0.AccessPartitionReferenceTsc = 1;
>>>>    synthetic_features.Bank0.AccessHypercallRegs = 1;
>>>>    synthetic_features.Bank0.AccessVpIndex = 1;
>>>> -    synthetic_features.Bank0.AccessHypercallRegs = 1;
>>> 
>>> ...but the code change seems to be removing one as well as
>>> adding the three new ones. Intentional?
>> Hello,
>> 
>> The AccessHypercallRegs bit was set twice - with the first one being two
>> lines earlier - removed a spurious one of the two.
> 
> Ah, right. How about this for a commit message ?
> 
> 
>    whpx: arm: enable more enlightenments
> 
>    Unconditionally enable some more enlightenments for whpx. In
>    particular, linux uses AccessVpRegs without checking availability and
>    panics if it's not there, so it's important to expose it.
> 
>    We also had a duplicate line where we set AccessHypercallRegs = 1
>    twice; remove the duplicate.
> 
> 
> If you have more rationale/info about the other two we're enabling,
> that would also be nice to include.
> 
> thanks
> -- PMM

Hello,


```
whpx: arm: enable more enlightenments

Enable some more enlightenments for whpx for -accel whpx,hyperv=on.
In particular, Linux uses AccessVpRegs without checking availability when
Hyper-V enlightenments are exposed and panics if it's not there.

We also had a duplicate line where we set AccessHypercallRegs = 1
twice; remove the duplicate.

Microsoft’s VMM exposes SyncContext on arm64 and FastHypercallOutput 
regardless of architecture unconditionally, so add those two to match 
that configuration.

```

On arm64, Hyper-V enlightenments with QEMU whpx aren’t on by default
and are a more research-y configuration - as the case when it was needed
to have a properly-behaved VM on Snapdragon X laptops has been worked around 
in Hyper-V.

Snapdragon X has broken CNTVOFF_EL2 with an interrupt flood when 
HCR_EL2.E2H = 1 + CNTVOFF_EL2 != 0 and Hyper-V synthetic timers were 
used on arm64 to sidestep that. Nowadays, Hyper-V has a workaround 
so that the virtual timer can be used instead of needing to resort
to using those.

Thanks,
-Mohamed

Re: [PATCH v3 3/6] whpx: arm: enable more enlightements

[Peter Maydell]

On Fri, 20 Mar 2026 at 09:50, Mohamed Mediouni <mohamed@unpredictable.fr> wrote:
>
>
> > On 20. Mar 2026, at 10:17, Peter Maydell <peter.maydell@linaro.org> wrote:
> >
> > On Thu, 19 Mar 2026 at 18:50, Mohamed Mediouni <mohamed@unpredictable.fr> wrote:
> >>
> >>
> >>> On 19. Mar 2026, at 19:13, Peter Maydell <peter.maydell@linaro.org> wrote:
> >>>
> >>> On Sat, 14 Mar 2026 at 22:15, Mohamed Mediouni <mohamed@unpredictable.fr> wrote:
> >>>>
> >>>> Linux uses AccessVpRegs without checking availability and panics if it's not there. Expose it unconditionally.
> >>>
> >>> The commit message subject says we're enabling enlightenments...
> >>>
> >>>> @@ -953,13 +953,15 @@ int whpx_accel_init(AccelState *as, MachineState *ms)
> >>>>    synthetic_features.Bank0.AccessPartitionReferenceTsc = 1;
> >>>>    synthetic_features.Bank0.AccessHypercallRegs = 1;
> >>>>    synthetic_features.Bank0.AccessVpIndex = 1;
> >>>> -    synthetic_features.Bank0.AccessHypercallRegs = 1;
> >>>
> >>> ...but the code change seems to be removing one as well as
> >>> adding the three new ones. Intentional?
> >> Hello,
> >>
> >> The AccessHypercallRegs bit was set twice - with the first one being two
> >> lines earlier - removed a spurious one of the two.
> >
> > Ah, right. How about this for a commit message ?
> >
> >
> >    whpx: arm: enable more enlightenments
> >
> >    Unconditionally enable some more enlightenments for whpx. In
> >    particular, linux uses AccessVpRegs without checking availability and
> >    panics if it's not there, so it's important to expose it.
> >
> >    We also had a duplicate line where we set AccessHypercallRegs = 1
> >    twice; remove the duplicate.
> >
> >
> > If you have more rationale/info about the other two we're enabling,
> > that would also be nice to include.

> ```
> whpx: arm: enable more enlightenments
>
> Enable some more enlightenments for whpx for -accel whpx,hyperv=on.
> In particular, Linux uses AccessVpRegs without checking availability when
> Hyper-V enlightenments are exposed and panics if it's not there.
>
> We also had a duplicate line where we set AccessHypercallRegs = 1
> twice; remove the duplicate.
>
> Microsoft’s VMM exposes SyncContext on arm64 and FastHypercallOutput
> regardless of architecture unconditionally, so add those two to match
> that configuration.
>
> ```

Thanks -- I've updated the commit message for this patch in
target-arm.next to that.

-- PMM

Re: [PATCH v3 0/6] whpx: arm: set of small fixes for QEMU 11.0

[Peter Maydell]

On Sat, 14 Mar 2026 at 22:15, Mohamed Mediouni <mohamed@unpredictable.fr> wrote:
>
> Localised fixes for QEMU 11.0:
>
> - fixes for -cpu host, including an ID_AA64MMFR2_EL1/ID_AA64MMFR3_EL1 mixup
> - add EC_DATAABORT assert for WHvRunVpExitReasonGpaIntercept/UnmappedGpa
>
> This one doesn't functionally change anything today, but is good to have and is a single-line change.
>
> - fix Hyper-V enlightenments
>
> AccessVpRegs turns out to be necessary too. Linux doesn't check for its presence and panics in an Hyper-V arm64
> configuration without it exposed.
>
> Fixing a mistake in not following the QEMU code style and having had AccessHypercallRegs included twice at the
> same time. Also add some more privileges because it looks like guests don't check for presence of each one
> systematically...
>
> - SME support shipped in Hyper-V now
>
> So remove a code comment. Another one-liner.


Applied to target-arm.next with commit message adjustments
as discussed, thanks.

-- PMM