MsvmPkg/AARCH64: Switch to ARM architectural timers#86
Conversation
|
How do you feel about alphabetization? |
| gArmTokenSpaceGuid.PcdArmArchTimerSecIntrNum|29 | ||
| gArmTokenSpaceGuid.PcdArmArchTimerIntrNum|19 | ||
| gArmTokenSpaceGuid.PcdArmArchTimerVirtIntrNum|20 | ||
| gArmTokenSpaceGuid.PcdArmArchTimerHypIntrNum|21 |
There was a problem hiding this comment.
[Copilot] PcdArmArchTimerHypIntrNum|21 is non-zero, so ArmPkg/Drivers/TimerDxe will call RegisterInterruptSource() for the EL2/hyp timer PPI and ASSERT_EFI_ERROR() on failure (see TimerInitialize() in ArmPkg/Drivers/TimerDxe/TimerDxe.c). The driver's own comment notes "The hypervisor timer interrupt may be omitted by implementations that execute under virtualization."
For a non-nested guest, UEFI runs at EL1, so the hyp timer register (CNTHP_EL2) isn't accessible and Hyper-V wouldn't deliver PPI 21 to firmware — suggesting this should be 0.
But this matters specifically for the ARM64 nested case: when mu_msvm runs as the L1 hypervisor's firmware, the guest does have EL2, and the EL2 timer PPI may actually be delivered. So the correct value is environment-dependent.
Two questions:
- In the non-nested (EL1-only) configuration, does Hyper-V actually deliver PPI 21? If not, hardcoding 21 risks a boot-time ASSERT — should it be
0? - If the intent is to support both nested and non-nested with one DSC, is 21 guaranteed safe in both? It'd be worth a comment here documenting the EL1-vs-EL2 assumption so the value isn't silently wrong when the nested-ness changes.
I knew you'd say that, which is one reason this is a draft. |
|
I like alphabetization. :)
Really? I mean, isn't this going back like 15+ years? |
Replace Hyper-V synthetic timer components with ARM architectural equivalents on AARCH64: - TimerLib: HvTimerLib -> ArmArchTimerLib (uses CNTVCT_EL0/CNTFRQ_EL0) - Timer DXE: SynicTimerDxe -> ArmPkg/Drivers/TimerDxe (generic timer + GIC) - ArmGenericTimerCounterLib: promoted from DxeMain-only to global This eliminates an unnecessary Hyper-V dependency. This is a prereq for using mu_msvm without Hyper-V enlightenments. We still use the synthetic timer infrastructure on x64, since we still support machines without invariant TSC, and Hyper-V has no other efficient invariant time source except hypervisor reference time.
Yeah, I hear you. I think we could at least conditionally use architectural timers on x64. I just don't have a pressing need to take that on. |
4 participants
Replace Hyper-V synthetic timer components with ARM architectural equivalents on AARCH64:
This eliminates an unnecessary Hyper-V dependency. This is a prereq for using mu_msvm without Hyper-V enlightenments.
We still use the synthetic timer infrastructure on x64, since we still support machines without invariant TSC, and Hyper-V has no other efficient invariant time source except hypervisor reference time.