whpx_arm_get_ipa_bit_size() declares WHV_CAPABILITY whpx_cap on the
stack and initializes it only via WHvGetCapability(). If that fails, the
error is reported but execution falls through to
round_down_to_parange_bit_size(whpx_cap.PhysicalAddressWidth), reading
an uninitialized value.

round_down_to_parange_index() searches pamax_map[] for the largest entry
that is <= the requested size and ends in g_assert_not_reached(). The
smallest valid PARange is 32, so any smaller value aborts QEMU.

Fix by setting PhysicalAddressWidth to 32, the smallest
architecturally valid PARange. Behaviour then becomes defined, and
where the guest memory map fits within that range initialization
continues on to the accelerator capability checks and their more
specific error messages.

Fixes: ea475a5ebb00 ("whpx: arm64: clamp down IPA size")

Signed-off-by: Doug Cook <dcook@microsoft.com>
---
 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 d106400686..dc70b33bc0 100644
--- a/target/arm/whpx/whpx-all.c
+++ b/target/arm/whpx/whpx-all.c
@@ -663,6 +663,7 @@ uint32_t whpx_arm_get_ipa_bit_size(void)
     if (FAILED(hr)) {
         error_report("WHPX: failed to get supported "
              "physical address width, hr=%08lx", hr);
+        whpx_cap.PhysicalAddressWidth = 32;
     }
 
     /*
-- 
2.55.0.vfs.0.8

> On 16. Sep 2026, at 23:49, Doug Cook (WINDOWS) <dcook@microsoft.com> wrote:
> 
> whpx_arm_get_ipa_bit_size() declares WHV_CAPABILITY whpx_cap on the
> stack and initializes it only via WHvGetCapability(). If that fails, the
> error is reported but execution falls through to
> round_down_to_parange_bit_size(whpx_cap.PhysicalAddressWidth), reading
> an uninitialized value.

Hi,

We have default values on the stack as initialised as 0 in QEMU.

> 
> round_down_to_parange_index() searches pamax_map[] for the largest entry
> that is <= the requested size and ends in g_assert_not_reached(). The
> smallest valid PARange is 32, so any smaller value aborts QEMU.
> 
> Fix by setting PhysicalAddressWidth to 32, the smallest
> architecturally valid PARange.

Where are you getting this condition? Is a certain Windows release broken
there that I’m not aware of?

Or is the hypervisor present check not happening early enough?
> Behaviour then becomes defined, and
> where the guest memory map fits within that range initialization
> continues on to the accelerator capability checks and their more
> specific error messages.
> 
> Fixes: ea475a5ebb00 ("whpx: arm64: clamp down IPA size")
> 
> Signed-off-by: Doug Cook <dcook@microsoft.com>
> ---
> 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 d106400686..dc70b33bc0 100644
> --- a/target/arm/whpx/whpx-all.c
> +++ b/target/arm/whpx/whpx-all.c
> @@ -663,6 +663,7 @@ uint32_t whpx_arm_get_ipa_bit_size(void)
>     if (FAILED(hr)) {
>         error_report("WHPX: failed to get supported "
>              "physical address width, hr=%08lx", hr);
> +        whpx_cap.PhysicalAddressWidth = 32;
>     }
> 
>     /*
> -- 
> 2.55.0.vfs.0.8

> On 17. Sep 2026, at 00:12, Mohamed Mediouni <mohamed@unpredictable.fr> wrote:
> 
> 
> 
>> On 16. Sep 2026, at 23:49, Doug Cook (WINDOWS) <dcook@microsoft.com> wrote:
>> 
>> whpx_arm_get_ipa_bit_size() declares WHV_CAPABILITY whpx_cap on the
>> stack and initializes it only via WHvGetCapability(). If that fails, the
>> error is reported but execution falls through to
>> round_down_to_parange_bit_size(whpx_cap.PhysicalAddressWidth), reading
>> an uninitialized value.
> 
> Hi,
> 
> We have default values on the stack as initialised as 0 in QEMU.
> 
>> 
>> round_down_to_parange_index() searches pamax_map[] for the largest entry
>> that is <= the requested size and ends in g_assert_not_reached(). The
>> smallest valid PARange is 32, so any smaller value aborts QEMU.
>> 
>> Fix by setting PhysicalAddressWidth to 32, the smallest
>> architecturally valid PARange.
> 
> Where are you getting this condition? Is a certain Windows release broken
> there that I’m not aware of?
> 
> Or is the hypervisor present check not happening early enough?

(On-list)

TL;DR at the end:

During a rebase before the initial WHPX merge, the fix for this
was dropped by mistake instead of a proper squash as was intended.

It was "whpx: arm64: check for physical address width after WHPX availability" at
https://lists.gnu.org/archive/html/qemu-devel/2025-10/msg07939.html

So I resubmitted that commit now.

>> Behaviour then becomes defined, and
>> where the guest memory map fits within that range initialization
>> continues on to the accelerator capability checks and their more
>> specific error messages.
>> 
>> Fixes: ea475a5ebb00 ("whpx: arm64: clamp down IPA size")
>> 
>> Signed-off-by: Doug Cook <dcook@microsoft.com>
>> ---
>> 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 d106400686..dc70b33bc0 100644
>> --- a/target/arm/whpx/whpx-all.c
>> +++ b/target/arm/whpx/whpx-all.c
>> @@ -663,6 +663,7 @@ uint32_t whpx_arm_get_ipa_bit_size(void)
>>    if (FAILED(hr)) {
>>        error_report("WHPX: failed to get supported "
>>             "physical address width, hr=%08lx", hr);
>> +        whpx_cap.PhysicalAddressWidth = 32;
>>    }
>> 
>>    /*
>> -- 
>> 2.55.0.vfs.0.8
> 
>