This one took way longer for me to publish than I should have.

There are a number of lingering bugs in this one including u-boot not working.

Interrupt controller save/restore is entirely missing in this RFC, and some other state
bits are likely still missing too.

ITS not blocked by default yet, remember to use its=off when testing this series.
You might also want the GICv3 + GICv2m support patch as part of the HVF vGIC patch series, which
is not duplicated here.

PS: on both this and HVF, interrupt controller initialisation needs to be done early so I ended
up with hardcoded addresses. Wonder if the right way to go might be to defer virt and vCPU initialisation
until late in the process post-gic_realize...

Other than that, this boots both EDK2 and Linux in SMP, when using devicetree or ACPI.

Mohamed Mediouni (9):
  whpx: Move around files before introducing AArch64 support
  whpx: reshuffle common code
  whpx: common: use whpx_cpu_instance_init on x86 only
  whpx: interrupt controller support
  hw/virt: make Qemu aware that WHPX has a vGICv3
  hw: intc: arm_gicv3_common: add whpx
  whpx: add arm64 support
  whpx: copy over memory tracking logic from hvf
  target/arm: cpu: mark WHPX as supporting PSCI 1.1

 accel/meson.build                             |   1 +
 accel/whpx/meson.build                        |   7 +
 {target/i386 => accel}/whpx/whpx-accel-ops.c  |   8 +-
 accel/whpx/whpx-common.c                      | 670 ++++++++++++++++
 hw/arm/virt.c                                 |   3 +
 hw/intc/arm_gicv3_common.c                    |   3 +
 hw/intc/arm_gicv3_whpx.c                      | 285 +++++++
 hw/intc/meson.build                           |   1 +
 .../whpx => include/system}/whpx-accel-ops.h  |   4 +-
 include/system/whpx-all.h                     |  12 +
 include/system/whpx-common.h                  |  22 +
 .../whpx => include/system}/whpx-internal.h   |  11 +-
 meson.build                                   |   5 +-
 target/arm/cpu.c                              |   3 +-
 target/arm/meson.build                        |   1 +
 target/arm/whpx/meson.build                   |   3 +
 target/arm/whpx/whpx-all.c                    | 744 ++++++++++++++++++
 target/i386/whpx/meson.build                  |   1 -
 target/i386/whpx/whpx-all.c                   | 524 +-----------
 target/i386/whpx/whpx-apic.c                  |   2 +-
 20 files changed, 1780 insertions(+), 530 deletions(-)
 create mode 100644 accel/whpx/meson.build
 rename {target/i386 => accel}/whpx/whpx-accel-ops.c (96%)
 create mode 100644 accel/whpx/whpx-common.c
 create mode 100644 hw/intc/arm_gicv3_whpx.c
 rename {target/i386/whpx => include/system}/whpx-accel-ops.h (92%)
 create mode 100644 include/system/whpx-all.h
 create mode 100644 include/system/whpx-common.h
 rename {target/i386/whpx => include/system}/whpx-internal.h (97%)
 create mode 100644 target/arm/whpx/meson.build
 create mode 100644 target/arm/whpx/whpx-all.c

-- 
2.39.5 (Apple Git-154)

Hi Mohamed,

On 7/30/25 10:27 PM, Mohamed Mediouni wrote:
> This one took way longer for me to publish than I should have.
> 
> There are a number of lingering bugs in this one including u-boot not working.
> 
> Interrupt controller save/restore is entirely missing in this RFC, and some other state
> bits are likely still missing too.
> 
> ITS not blocked by default yet, remember to use its=off when testing this series.
> You might also want the GICv3 + GICv2m support patch as part of the HVF vGIC patch series, which
> is not duplicated here.
> 
> PS: on both this and HVF, interrupt controller initialisation needs to be done early so I ended
> up with hardcoded addresses. Wonder if the right way to go might be to defer virt and vCPU initialisation
> until late in the process post-gic_realize...
> 
> Other than that, this boots both EDK2 and Linux in SMP, when using devicetree or ACPI.
> 

thanks for posting this, that's an exciting series!

I applied it on top of your other series 
(20250728134114.77545-1-mohamed@unpredictable.fr) and solved the conflicts.
However, it would really help if you could push that exact branch 
somewhere, so people can easily pull it and try.
I'm fine if you want to duplicate gic patches in this series as well.

I tried to direct boot a kernel (6.15 defconfig) and ran into this error 
[1]:
$ ./build/qemu-system-aarch64.exe -M virt,its=off -cpu cortex-a76 -m 2G 
-nographic -accel whpx -kernel out/Image.gz out/host.ext4

Could you please share your exact command line?
Does it work with direct kernel boot also?

Kind Regards,
Pierrick

[1] Error when booting:
[    1.381525] Internal error: Oops: 0000000096000002 [#1]  SMP
[    1.458060] Modules linked in:
[    1.461172] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 
6.15.0-00001-g7797e43a2520 #1 PREEMPT
[    1.470502] Hardware name: linux,dummy-virt (DT)
[    1.475102] pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS 
BTYPE=--)
[    1.482023] pc : pci_generic_config_read+0x38/0xb8
[    1.486970] lr : pci_generic_config_read+0x24/0xb8
[    1.491734] sp : ffff80008000b940
[    1.495079] x29: ffff80008000b940 x28: 0000000000000000 x27: 
ffffbb8fe13f00ec
[    1.502473] x26: ffffbb8fe14f9060 x25: ffffbb8fe14f9078 x24: 
ffffbb8fe1c99990
[    1.509564] x23: 0000000000000000 x22: ffff80008000b9f4 x21: 
ffff574c83b7c000
[    1.516636] x20: ffff80008000b964 x19: 0000000000000004 x18: 
0000000000000006
[    1.523722] x17: 6666666666666666 x16: 6678302d30303030 x15: 
0720072007200720
[    1.531583] x14: 0720072007200720 x13: 0720072007200720 x12: 
ffffbb8fe1736838
[    1.539094] x11: 0000000000000058 x10: 0000000000000018 x9 : 
ffffbb8fe1736838
[    1.546212] x8 : 00000000000000c5 x7 : ffffbb8fe187ff40 x6 : 
00000000000000ff
[    1.553370] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 
ffff800090000000
[    1.560676] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 
ffff800090000000
[    1.567890] Call trace:
[    1.570509]  pci_generic_config_read+0x38/0xb8 (P)
[    1.575362]  pci_bus_read_config_dword+0x80/0xe4
[    1.580231]  pci_bus_generic_read_dev_vendor_id+0x30/0x164
[    1.586164]  pci_scan_single_device+0x118/0x18c
[    1.590912]  pci_scan_slot+0x58/0x214
[    1.594782]  pci_scan_child_bus_extend+0x40/0x234
[    1.599606]  pci_scan_root_bus_bridge+0x64/0xd8
[    1.604194]  pci_host_probe+0x30/0xec
[    1.607972]  pci_host_common_probe+0x128/0x1c0
[    1.612430]  platform_probe+0x68/0xdc
[    1.616220]  really_probe+0xbc/0x2c0
[    1.619814]  __driver_probe_device+0x78/0x120
[    1.624435]  driver_probe_device+0x3c/0x154
[    1.628620]  __driver_attach+0x90/0x1a0
[    1.632509]  bus_for_each_dev+0x7c/0xdc
[    1.636449]  driver_attach+0x24/0x30
[    1.640067]  bus_add_driver+0xe4/0x208
[    1.643774]  driver_register+0x68/0x130
[    1.647667]  __platform_driver_register+0x24/0x30
[    1.652704]  gen_pci_driver_init+0x1c/0x28
[    1.657181]  do_one_initcall+0x60/0x1d4
[    1.661172]  kernel_init_freeable+0x210/0x274
[    1.665749]  kernel_init+0x20/0x140
[    1.669341]  ret_from_fork+0x10/0x20
[    1.673034] Code: 7100067f 540002c0 71000a7f 54000180 (b9400000)

> On 1. Aug 2025, at 03:15, Pierrick Bouvier <pierrick.bouvier@linaro.org> wrote:
> 
> Hi Mohamed,
> 
> On 7/30/25 10:27 PM, Mohamed Mediouni wrote:
>> This one took way longer for me to publish than I should have.
>> There are a number of lingering bugs in this one including u-boot not working.
>> Interrupt controller save/restore is entirely missing in this RFC, and some other state
>> bits are likely still missing too.
>> ITS not blocked by default yet, remember to use its=off when testing this series.
>> You might also want the GICv3 + GICv2m support patch as part of the HVF vGIC patch series, which
>> is not duplicated here.
>> PS: on both this and HVF, interrupt controller initialisation needs to be done early so I ended
>> up with hardcoded addresses. Wonder if the right way to go might be to defer virt and vCPU initialisation
>> until late in the process post-gic_realize...
>> Other than that, this boots both EDK2 and Linux in SMP, when using devicetree or ACPI.
> 
> thanks for posting this, that's an exciting series!
> 
> I applied it on top of your other series (20250728134114.77545-1-mohamed@unpredictable.fr) and solved the conflicts.
> However, it would really help if you could push that exact branch somewhere, so people can easily pull it and try.
> I'm fine if you want to duplicate gic patches in this series as well.
Hello,

My branches are at https://github.com/mediouni-m/qemu

whpx-v1 corresponding to this RFC, but latest rev of the whpx branch has some fixes

Have some additional notes and binaries here too: https://github.com/mediouni-m/qemu/releases/tag/whpx-v1.1

Thank you,
-Mohamed

> I tried to direct boot a kernel (6.15 defconfig) and ran into this error [1]:
> $ ./build/qemu-system-aarch64.exe -M virt,its=off -cpu cortex-a76 -m 2G -nographic -accel whpx -kernel out/Image.gz out/host.ext4

Syntax that I use is -M virt,accel=whpx,its=off -m 2048-cpu cortex-a72 -bios share/edk2-aarch64-code.fd.

And on some kernel versions, you’ll also need irqchip.gicv3_nolpi=1.

> Could you please share your exact command line?
> Does it work with direct kernel boot also?
> 
> Kind Regards,
> Pierrick
> 
> [1] Error when booting:
> [    1.381525] Internal error: Oops: 0000000096000002 [#1]  SMP
> [    1.458060] Modules linked in:
> [    1.461172] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.15.0-00001-g7797e43a2520 #1 PREEMPT
> [    1.470502] Hardware name: linux,dummy-virt (DT)
> [    1.475102] pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [    1.482023] pc : pci_generic_config_read+0x38/0xb8
> [    1.486970] lr : pci_generic_config_read+0x24/0xb8
I don’t think I saw this particular one before… which Windows version and hardware are you testing this on?

(Message was sent from the wrong email alias on mobile, resending)
Thank you,
-Mohamed

On 8/1/25 5:43 AM, Mohamed Mediouni wrote:
> 
> 
>> On 1. Aug 2025, at 03:15, Pierrick Bouvier <pierrick.bouvier@linaro.org> wrote:
>>
>> Hi Mohamed,
>>
>> On 7/30/25 10:27 PM, Mohamed Mediouni wrote:
>>> This one took way longer for me to publish than I should have.
>>> There are a number of lingering bugs in this one including u-boot not working.
>>> Interrupt controller save/restore is entirely missing in this RFC, and some other state
>>> bits are likely still missing too.
>>> ITS not blocked by default yet, remember to use its=off when testing this series.
>>> You might also want the GICv3 + GICv2m support patch as part of the HVF vGIC patch series, which
>>> is not duplicated here.
>>> PS: on both this and HVF, interrupt controller initialisation needs to be done early so I ended
>>> up with hardcoded addresses. Wonder if the right way to go might be to defer virt and vCPU initialisation
>>> until late in the process post-gic_realize...
>>> Other than that, this boots both EDK2 and Linux in SMP, when using devicetree or ACPI.
>>
>> thanks for posting this, that's an exciting series!
>>
>> I applied it on top of your other series (20250728134114.77545-1-mohamed@unpredictable.fr) and solved the conflicts.
>> However, it would really help if you could push that exact branch somewhere, so people can easily pull it and try.
>> I'm fine if you want to duplicate gic patches in this series as well.
> Hello,
> 
> My branches are at https://github.com/mediouni-m/qemu
>

Thanks, it's worth adding it in cover letter for next versions.

> whpx-v1 corresponding to this RFC, but latest rev of the whpx branch has some fixes
> 
> Have some additional notes and binaries here too: https://github.com/mediouni-m/qemu/releases/tag/whpx-v1.1
> 
> Thank you,
> -Mohamed
> 
>> I tried to direct boot a kernel (6.15 defconfig) and ran into this error [1]:
>> $ ./build/qemu-system-aarch64.exe -M virt,its=off -cpu cortex-a76 -m 2G -nographic -accel whpx -kernel out/Image.gz out/host.ext4
> 
> Syntax that I use is -M virt,accel=whpx,its=off -m 2048-cpu cortex-a72 -bios share/edk2-aarch64-code.fd.
> 
> And on some kernel versions, you’ll also need irqchip.gicv3_nolpi=1.
> 
>> Could you please share your exact command line?
>> Does it work with direct kernel boot also?
>>
>> Kind Regards,
>> Pierrick
>>
>> [1] Error when booting:
>> [    1.381525] Internal error: Oops: 0000000096000002 [#1]  SMP
>> [    1.458060] Modules linked in:
>> [    1.461172] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.15.0-00001-g7797e43a2520 #1 PREEMPT
>> [    1.470502] Hardware name: linux,dummy-virt (DT)
>> [    1.475102] pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>> [    1.482023] pc : pci_generic_config_read+0x38/0xb8
>> [    1.486970] lr : pci_generic_config_read+0x24/0xb8
> I don’t think I saw this particular one before… which Windows version and hardware are you testing this on?
>

I see the same error as before.

I tried also binaries from 
https://github.com/mediouni-m/qemu/releases/tag/whpx-v1.1, when directly 
booting kernel, I still see the same pci issue with both binaries and my 
compiled whpx-v1.3.
When booting edk2 provided, I ran into this other error instead with 
both binaries [1].

I'm running latest Windows 11 (stable channel, fully updated), on a 
microsoft volterra (devkit). It might be an issue specific to this platform.

In case you're interested, we can arrange an access to the machine, but 
I understand if it's not your priority now.

[1]
Windows Hypervisor Platform accelerator is operational
UEFI firmware (version edk2-stable202408-prebuilt.qemu.org built at 
16:28:50 on Sep 12 2024)
ArmTrngLib could not be correctly initialized.
Error: Image at 000BFDB6000 start failed: 00000001
Error: Image at 000BFD6D000 start failed: Not Found
MapGcdMmioSpace: failed to add GCD memory space for region 
[0x4010000000+0x10000000)
ASSERT_EFI_ERROR (Status = Unsupported)
ASSERT [PciHostBridgeDxe] 
/home/kraxel/projects/qemu/roms/edk2/OvmfPkg/Fdt/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c(326): 
!(((INTN)(RETURN_STATUS)(Status)) < 0)

> (Message was sent from the wrong email alias on mobile, resending)
> Thank you,
> -Mohamed
> 

Thanks,
Pierrick

> On 1. Aug 2025, at 19:22, Pierrick Bouvier <pierrick.bouvier@linaro.org> wrote:
> 
> On 8/1/25 5:43 AM, Mohamed Mediouni wrote:
>>> On 1. Aug 2025, at 03:15, Pierrick Bouvier <pierrick.bouvier@linaro.org> wrote:
>>> 
>>> Hi Mohamed,
>>> 
>>> On 7/30/25 10:27 PM, Mohamed Mediouni wrote:
>>>> This one took way longer for me to publish than I should have.
>>>> There are a number of lingering bugs in this one including u-boot not working.
>>>> Interrupt controller save/restore is entirely missing in this RFC, and some other state
>>>> bits are likely still missing too.
>>>> ITS not blocked by default yet, remember to use its=off when testing this series.
>>>> You might also want the GICv3 + GICv2m support patch as part of the HVF vGIC patch series, which
>>>> is not duplicated here.
>>>> PS: on both this and HVF, interrupt controller initialisation needs to be done early so I ended
>>>> up with hardcoded addresses. Wonder if the right way to go might be to defer virt and vCPU initialisation
>>>> until late in the process post-gic_realize...
>>>> Other than that, this boots both EDK2 and Linux in SMP, when using devicetree or ACPI.
>>> 
>>> thanks for posting this, that's an exciting series!
>>> 
>>> I applied it on top of your other series (20250728134114.77545-1-mohamed@unpredictable.fr) and solved the conflicts.
>>> However, it would really help if you could push that exact branch somewhere, so people can easily pull it and try.
>>> I'm fine if you want to duplicate gic patches in this series as well.
>> Hello,
>> My branches are at https://github.com/mediouni-m/qemu
>> 
> 
> Thanks, it's worth adding it in cover letter for next versions.
> 
>> whpx-v1 corresponding to this RFC, but latest rev of the whpx branch has some fixes
>> Have some additional notes and binaries here too: https://github.com/mediouni-m/qemu/releases/tag/whpx-v1.1
>> Thank you,
>> -Mohamed
>>> I tried to direct boot a kernel (6.15 defconfig) and ran into this error [1]:
>>> $ ./build/qemu-system-aarch64.exe -M virt,its=off -cpu cortex-a76 -m 2G -nographic -accel whpx -kernel out/Image.gz out/host.ext4
>> Syntax that I use is -M virt,accel=whpx,its=off -m 2048-cpu cortex-a72 -bios share/edk2-aarch64-code.fd.
>> And on some kernel versions, you’ll also need irqchip.gicv3_nolpi=1.
>>> Could you please share your exact command line?
>>> Does it work with direct kernel boot also?
>>> 
>>> Kind Regards,
>>> Pierrick
>>> 
>>> [1] Error when booting:
>>> [    1.381525] Internal error: Oops: 0000000096000002 [#1]  SMP
>>> [    1.458060] Modules linked in:
>>> [    1.461172] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.15.0-00001-g7797e43a2520 #1 PREEMPT
>>> [    1.470502] Hardware name: linux,dummy-virt (DT)
>>> [    1.475102] pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>>> [    1.482023] pc : pci_generic_config_read+0x38/0xb8
>>> [    1.486970] lr : pci_generic_config_read+0x24/0xb8
>> I don’t think I saw this particular one before… which Windows version and hardware are you testing this on?
>> 
> 
> I see the same error as before.
> 
> I tried also binaries from https://github.com/mediouni-m/qemu/releases/tag/whpx-v1.1, when directly booting kernel, I still see the same pci issue with both binaries and my compiled whpx-v1.3.
> When booting edk2 provided, I ran into this other error instead with both binaries [1].
> 
> I'm running latest Windows 11 (stable channel, fully updated), on a microsoft volterra (devkit). It might be an issue specific to this platform.
> 
I didn’t test anything on the stable branch for now but only on Canary so far. 
Just cursorily tested (EDK2 only) an X Elite device on prod (26100.4652) and this issue doesn’t appear.

I have 8cx Gen 3 and 8cx Gen 1 (SQ1) devices around, will test on those older SoCs later and see.

Random idea for testing: what if you put -M highmem=off, does that change anything?

Thanks,
-Mohamed

> In case you're interested, we can arrange an access to the machine, but I understand if it's not your priority now.
> 
> [1]
> Windows Hypervisor Platform accelerator is operational
> UEFI firmware (version edk2-stable202408-prebuilt.qemu.org built at 16:28:50 on Sep 12 2024)
> ArmTrngLib could not be correctly initialized.
> Error: Image at 000BFDB6000 start failed: 00000001
> Error: Image at 000BFD6D000 start failed: Not Found
> MapGcdMmioSpace: failed to add GCD memory space for region [0x4010000000+0x10000000)
> ASSERT_EFI_ERROR (Status = Unsupported)
> ASSERT [PciHostBridgeDxe] /home/kraxel/projects/qemu/roms/edk2/OvmfPkg/Fdt/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c(326): !(((INTN)(RETURN_STATUS)(Status)) < 0)
> 
>> (Message was sent from the wrong email alias on mobile, resending)
>> Thank you,
>> -Mohamed
> 
> Thanks,
> Pierrick

On 8/1/25 11:52 AM, Mohamed Mediouni wrote:
> 
> 
>> On 1. Aug 2025, at 19:22, Pierrick Bouvier <pierrick.bouvier@linaro.org> wrote:
>>
>> On 8/1/25 5:43 AM, Mohamed Mediouni wrote:
>>>> On 1. Aug 2025, at 03:15, Pierrick Bouvier <pierrick.bouvier@linaro.org> wrote:
>>>>
>>>> Hi Mohamed,
>>>>
>>>> On 7/30/25 10:27 PM, Mohamed Mediouni wrote:
>>>>> This one took way longer for me to publish than I should have.
>>>>> There are a number of lingering bugs in this one including u-boot not working.
>>>>> Interrupt controller save/restore is entirely missing in this RFC, and some other state
>>>>> bits are likely still missing too.
>>>>> ITS not blocked by default yet, remember to use its=off when testing this series.
>>>>> You might also want the GICv3 + GICv2m support patch as part of the HVF vGIC patch series, which
>>>>> is not duplicated here.
>>>>> PS: on both this and HVF, interrupt controller initialisation needs to be done early so I ended
>>>>> up with hardcoded addresses. Wonder if the right way to go might be to defer virt and vCPU initialisation
>>>>> until late in the process post-gic_realize...
>>>>> Other than that, this boots both EDK2 and Linux in SMP, when using devicetree or ACPI.
>>>>
>>>> thanks for posting this, that's an exciting series!
>>>>
>>>> I applied it on top of your other series (20250728134114.77545-1-mohamed@unpredictable.fr) and solved the conflicts.
>>>> However, it would really help if you could push that exact branch somewhere, so people can easily pull it and try.
>>>> I'm fine if you want to duplicate gic patches in this series as well.
>>> Hello,
>>> My branches are at https://github.com/mediouni-m/qemu
>>>
>>
>> Thanks, it's worth adding it in cover letter for next versions.
>>
>>> whpx-v1 corresponding to this RFC, but latest rev of the whpx branch has some fixes
>>> Have some additional notes and binaries here too: https://github.com/mediouni-m/qemu/releases/tag/whpx-v1.1
>>> Thank you,
>>> -Mohamed
>>>> I tried to direct boot a kernel (6.15 defconfig) and ran into this error [1]:
>>>> $ ./build/qemu-system-aarch64.exe -M virt,its=off -cpu cortex-a76 -m 2G -nographic -accel whpx -kernel out/Image.gz out/host.ext4
>>> Syntax that I use is -M virt,accel=whpx,its=off -m 2048-cpu cortex-a72 -bios share/edk2-aarch64-code.fd.
>>> And on some kernel versions, you’ll also need irqchip.gicv3_nolpi=1.
>>>> Could you please share your exact command line?
>>>> Does it work with direct kernel boot also?
>>>>
>>>> Kind Regards,
>>>> Pierrick
>>>>
>>>> [1] Error when booting:
>>>> [    1.381525] Internal error: Oops: 0000000096000002 [#1]  SMP
>>>> [    1.458060] Modules linked in:
>>>> [    1.461172] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.15.0-00001-g7797e43a2520 #1 PREEMPT
>>>> [    1.470502] Hardware name: linux,dummy-virt (DT)
>>>> [    1.475102] pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>>>> [    1.482023] pc : pci_generic_config_read+0x38/0xb8
>>>> [    1.486970] lr : pci_generic_config_read+0x24/0xb8
>>> I don’t think I saw this particular one before… which Windows version and hardware are you testing this on?
>>>
>>
>> I see the same error as before.
>>
>> I tried also binaries from https://github.com/mediouni-m/qemu/releases/tag/whpx-v1.1, when directly booting kernel, I still see the same pci issue with both binaries and my compiled whpx-v1.3.
>> When booting edk2 provided, I ran into this other error instead with both binaries [1].
>>
>> I'm running latest Windows 11 (stable channel, fully updated), on a microsoft volterra (devkit). It might be an issue specific to this platform.
>>
> I didn’t test anything on the stable branch for now but only on Canary so far.
> Just cursorily tested (EDK2 only) an X Elite device on prod (26100.4652) and this issue doesn’t appear.
> 
> I have 8cx Gen 3 and 8cx Gen 1 (SQ1) devices around, will test on those older SoCs later and see.
> 
> Random idea for testing: what if you put -M highmem=off, does that change anything?
>

Good guess, it solves the problem with edk2, and direct boots linux 
kernel successfully now.

> Thanks,
> -Mohamed
> 
>> In case you're interested, we can arrange an access to the machine, but I understand if it's not your priority now.
>>
>> [1]
>> Windows Hypervisor Platform accelerator is operational
>> UEFI firmware (version edk2-stable202408-prebuilt.qemu.org built at 16:28:50 on Sep 12 2024)
>> ArmTrngLib could not be correctly initialized.
>> Error: Image at 000BFDB6000 start failed: 00000001
>> Error: Image at 000BFD6D000 start failed: Not Found
>> MapGcdMmioSpace: failed to add GCD memory space for region [0x4010000000+0x10000000)
>> ASSERT_EFI_ERROR (Status = Unsupported)
>> ASSERT [PciHostBridgeDxe] /home/kraxel/projects/qemu/roms/edk2/OvmfPkg/Fdt/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c(326): !(((INTN)(RETURN_STATUS)(Status)) < 0)
>>
>>> (Message was sent from the wrong email alias on mobile, resending)
>>> Thank you,
>>> -Mohamed
>>
>> Thanks,
>> Pierrick
> 

> On 1. Aug 2025, at 21:16, Pierrick Bouvier <pierrick.bouvier@linaro.org> wrote:
> 
> On 8/1/25 11:52 AM, Mohamed Mediouni wrote:
>>> On 1. Aug 2025, at 19:22, Pierrick Bouvier <pierrick.bouvier@linaro.org> wrote:
>>> 
>>> On 8/1/25 5:43 AM, Mohamed Mediouni wrote:
>>>>> On 1. Aug 2025, at 03:15, Pierrick Bouvier <pierrick.bouvier@linaro.org> wrote:
>>>>> 
>>>>> Hi Mohamed,
>>>>> 
>>>>> On 7/30/25 10:27 PM, Mohamed Mediouni wrote:
>>>>>> This one took way longer for me to publish than I should have.
>>>>>> There are a number of lingering bugs in this one including u-boot not working.
>>>>>> Interrupt controller save/restore is entirely missing in this RFC, and some other state
>>>>>> bits are likely still missing too.
>>>>>> ITS not blocked by default yet, remember to use its=off when testing this series.
>>>>>> You might also want the GICv3 + GICv2m support patch as part of the HVF vGIC patch series, which
>>>>>> is not duplicated here.
>>>>>> PS: on both this and HVF, interrupt controller initialisation needs to be done early so I ended
>>>>>> up with hardcoded addresses. Wonder if the right way to go might be to defer virt and vCPU initialisation
>>>>>> until late in the process post-gic_realize...
>>>>>> Other than that, this boots both EDK2 and Linux in SMP, when using devicetree or ACPI.
>>>>> 
>>>>> thanks for posting this, that's an exciting series!
>>>>> 
>>>>> I applied it on top of your other series (20250728134114.77545-1-mohamed@unpredictable.fr) and solved the conflicts.
>>>>> However, it would really help if you could push that exact branch somewhere, so people can easily pull it and try.
>>>>> I'm fine if you want to duplicate gic patches in this series as well.
>>>> Hello,
>>>> My branches are at https://github.com/mediouni-m/qemu
>>>> 
>>> 
>>> Thanks, it's worth adding it in cover letter for next versions.
>>> 
>>>> whpx-v1 corresponding to this RFC, but latest rev of the whpx branch has some fixes
>>>> Have some additional notes and binaries here too: https://github.com/mediouni-m/qemu/releases/tag/whpx-v1.1
>>>> Thank you,
>>>> -Mohamed
>>>>> I tried to direct boot a kernel (6.15 defconfig) and ran into this error [1]:
>>>>> $ ./build/qemu-system-aarch64.exe -M virt,its=off -cpu cortex-a76 -m 2G -nographic -accel whpx -kernel out/Image.gz out/host.ext4
>>>> Syntax that I use is -M virt,accel=whpx,its=off -m 2048-cpu cortex-a72 -bios share/edk2-aarch64-code.fd.
>>>> And on some kernel versions, you’ll also need irqchip.gicv3_nolpi=1.
>>>>> Could you please share your exact command line?
>>>>> Does it work with direct kernel boot also?
>>>>> 
>>>>> Kind Regards,
>>>>> Pierrick
>>>>> 
>>>>> [1] Error when booting:
>>>>> [    1.381525] Internal error: Oops: 0000000096000002 [#1]  SMP
>>>>> [    1.458060] Modules linked in:
>>>>> [    1.461172] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.15.0-00001-g7797e43a2520 #1 PREEMPT
>>>>> [    1.470502] Hardware name: linux,dummy-virt (DT)
>>>>> [    1.475102] pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>>>>> [    1.482023] pc : pci_generic_config_read+0x38/0xb8
>>>>> [    1.486970] lr : pci_generic_config_read+0x24/0xb8
>>>> I don’t think I saw this particular one before… which Windows version and hardware are you testing this on?
>>>> 
>>> 
>>> I see the same error as before.
>>> 
>>> I tried also binaries from https://github.com/mediouni-m/qemu/releases/tag/whpx-v1.1, when directly booting kernel, I still see the same pci issue with both binaries and my compiled whpx-v1.3.
>>> When booting edk2 provided, I ran into this other error instead with both binaries [1].
>>> 
>>> I'm running latest Windows 11 (stable channel, fully updated), on a microsoft volterra (devkit). It might be an issue specific to this platform.
>>> 
>> I didn’t test anything on the stable branch for now but only on Canary so far.
>> Just cursorily tested (EDK2 only) an X Elite device on prod (26100.4652) and this issue doesn’t appear.
>> I have 8cx Gen 3 and 8cx Gen 1 (SQ1) devices around, will test on those older SoCs later and see.
>> Random idea for testing: what if you put -M highmem=off, does that change anything?
>> 
> 
> Good guess, it solves the problem with edk2, and direct boots linux kernel successfully now.
> 

If you don’t mind, could you please test the latest commit I just put on the Git repo (whpx branch)? It should address this properly.

Thank you,
-Mohamed

On 8/1/25 12:31 PM, Mohamed Mediouni wrote:
>>> I didn’t test anything on the stable branch for now but only on Canary so far.
>>> Just cursorily tested (EDK2 only) an X Elite device on prod (26100.4652) and this issue doesn’t appear.
>>> I have 8cx Gen 3 and 8cx Gen 1 (SQ1) devices around, will test on those older SoCs later and see.
>>> Random idea for testing: what if you put -M highmem=off, does that change anything?
>>>
>>
>> Good guess, it solves the problem with edk2, and direct boots linux kernel successfully now.
>>
> 
> If you don’t mind, could you please test the latest commit I just put on the Git repo (whpx branch)? It should address this properly.
> 

Sure.
Without highmem=off, I get a new error:
Physical address width: 36
C:\msys64\home\tcwg\qemu\build\qemu-system-aarch64.exe: VCPU supports 
less PA bits (36) than requested by the memory map (40)

> On 1. Aug 2025, at 21:42, Pierrick Bouvier <pierrick.bouvier@linaro.org> wrote:
> 
> On 8/1/25 12:31 PM, Mohamed Mediouni wrote:
>>>> I didn’t test anything on the stable branch for now but only on Canary so far.
>>>> Just cursorily tested (EDK2 only) an X Elite device on prod (26100.4652) and this issue doesn’t appear.
>>>> I have 8cx Gen 3 and 8cx Gen 1 (SQ1) devices around, will test on those older SoCs later and see.
>>>> Random idea for testing: what if you put -M highmem=off, does that change anything?
>>>> 
>>> 
>>> Good guess, it solves the problem with edk2, and direct boots linux kernel successfully now.
>>> 
>> If you don’t mind, could you please test the latest commit I just put on the Git repo (whpx branch)? It should address this properly.
> 
> Sure.
> Without highmem=off, I get a new error:
> Physical address width: 36
> C:\msys64\home\tcwg\qemu\build\qemu-system-aarch64.exe: VCPU supports less PA bits (36) than requested by the memory map (40)
> 
Oh this confirms what I thought, just pushed a new commit which should be a complete fix. :)

And accessorily is also a good thing for Snapdragon X too, as 40 VA bits were used there despite the hardware having 39.

Thank you,
-Mohamed

On 8/1/25 12:57 PM, Mohamed Mediouni wrote:
> 
> 
>> On 1. Aug 2025, at 21:42, Pierrick Bouvier <pierrick.bouvier@linaro.org> wrote:
>>
>> On 8/1/25 12:31 PM, Mohamed Mediouni wrote:
>>>>> I didn’t test anything on the stable branch for now but only on Canary so far.
>>>>> Just cursorily tested (EDK2 only) an X Elite device on prod (26100.4652) and this issue doesn’t appear.
>>>>> I have 8cx Gen 3 and 8cx Gen 1 (SQ1) devices around, will test on those older SoCs later and see.
>>>>> Random idea for testing: what if you put -M highmem=off, does that change anything?
>>>>>
>>>>
>>>> Good guess, it solves the problem with edk2, and direct boots linux kernel successfully now.
>>>>
>>> If you don’t mind, could you please test the latest commit I just put on the Git repo (whpx branch)? It should address this properly.
>>
>> Sure.
>> Without highmem=off, I get a new error:
>> Physical address width: 36
>> C:\msys64\home\tcwg\qemu\build\qemu-system-aarch64.exe: VCPU supports less PA bits (36) than requested by the memory map (40)
>>
> Oh this confirms what I thought, just pushed a new commit which should be a complete fix. :)
>

It works fine now, on top of c6e3d4d.
Excellent work!

> And accessorily is also a good thing for Snapdragon X too, as 40 VA bits were used there despite the hardware having 39.
>

Yes.

> Thank you,
> -Mohamed

This seems like a good time for cleaning up, address the few comments 
that have been made, and send a v2.
Feel free to add the gic related patches in it, so we have a "complete" 
series to review.

Thanks,
Pierrick