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)

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

> 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

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

> 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

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