> On 16. Sep 2026, at 23:49, Doug Cook (WINDOWS) <[email protected]> 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 <[email protected]>
> ---
> 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
