| Message ID | 20190729153944.24239-30-anthony.perard@citrix.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Specific platform to run OVMF in Xen PVH and HVM guests | expand |
On Mon, Jul 29, 2019 at 04:39:38PM +0100, Anthony PERARD wrote: > PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib > implementation. It will also be used by XenTimerDxe. Override > PcdFSBClock to match Xen vLAPIC timer frequency. I'm kind of surprised that his is not automatically detected? Is it a bug in Xen or just always hardcoded on OVMF? Thanks, Roger.
On Wed, Aug 07, 2019 at 05:54:51PM +0200, Roger Pau Monné wrote: > On Mon, Jul 29, 2019 at 04:39:38PM +0100, Anthony PERARD wrote: > > PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib > > implementation. It will also be used by XenTimerDxe. Override > > PcdFSBClock to match Xen vLAPIC timer frequency. > > I'm kind of surprised that his is not automatically detected? > > Is it a bug in Xen or just always hardcoded on OVMF? It's hardcoded. Why would you need auto detection when you always run on the same machine ;-).
On Thu, Aug 08, 2019 at 02:28:32PM +0100, Anthony PERARD wrote: > On Wed, Aug 07, 2019 at 05:54:51PM +0200, Roger Pau Monné wrote: > > On Mon, Jul 29, 2019 at 04:39:38PM +0100, Anthony PERARD wrote: > > > PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib > > > implementation. It will also be used by XenTimerDxe. Override > > > PcdFSBClock to match Xen vLAPIC timer frequency. > > > > I'm kind of surprised that his is not automatically detected? > > > > Is it a bug in Xen or just always hardcoded on OVMF? > > It's hardcoded. Why would you need auto detection when you always run on > the same machine ;-). I don't think that's part of the HVM/PVH ABI in any way, and if you hardcode it in OVMF it would prevent Xen from changing the frequency in the future if such necessity arises. We should try to avoid painting ourselves into a corner when possible. Doesn't OVMF have a way to get this from the hardware itself? Thanks, Roger.
On Thu, Aug 08, 2019 at 03:44:23PM +0200, Roger Pau Monné wrote: > On Thu, Aug 08, 2019 at 02:28:32PM +0100, Anthony PERARD wrote: > > On Wed, Aug 07, 2019 at 05:54:51PM +0200, Roger Pau Monné wrote: > > > On Mon, Jul 29, 2019 at 04:39:38PM +0100, Anthony PERARD wrote: > > > > PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib > > > > implementation. It will also be used by XenTimerDxe. Override > > > > PcdFSBClock to match Xen vLAPIC timer frequency. > > > > > > I'm kind of surprised that his is not automatically detected? > > > > > > Is it a bug in Xen or just always hardcoded on OVMF? > > > > It's hardcoded. Why would you need auto detection when you always run on > > the same machine ;-). > > I don't think that's part of the HVM/PVH ABI in any way, and if you > hardcode it in OVMF it would prevent Xen from changing the frequency > in the future if such necessity arises. We should try to avoid painting > ourselves into a corner when possible. > > Doesn't OVMF have a way to get this from the hardware itself? So EDKII doesn't have that capability, FSBClock is a build time value and can't be changed at run time. But OVMF (on KVM or HVM) doesn't use that value at all, it uses the ACPI timer instead. We could try to find a better way to get time in OvmfXen without hardcoding FSBClock, but maybe in a follow-up. Thanks,
On Thu, Aug 08, 2019 at 03:26:41PM +0100, Anthony PERARD wrote: > On Thu, Aug 08, 2019 at 03:44:23PM +0200, Roger Pau Monné wrote: > > On Thu, Aug 08, 2019 at 02:28:32PM +0100, Anthony PERARD wrote: > > > On Wed, Aug 07, 2019 at 05:54:51PM +0200, Roger Pau Monné wrote: > > > > On Mon, Jul 29, 2019 at 04:39:38PM +0100, Anthony PERARD wrote: > > > > > PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib > > > > > implementation. It will also be used by XenTimerDxe. Override > > > > > PcdFSBClock to match Xen vLAPIC timer frequency. > > > > > > > > I'm kind of surprised that his is not automatically detected? > > > > > > > > Is it a bug in Xen or just always hardcoded on OVMF? > > > > > > It's hardcoded. Why would you need auto detection when you always run on > > > the same machine ;-). > > > > I don't think that's part of the HVM/PVH ABI in any way, and if you > > hardcode it in OVMF it would prevent Xen from changing the frequency > > in the future if such necessity arises. We should try to avoid painting > > ourselves into a corner when possible. > > > > Doesn't OVMF have a way to get this from the hardware itself? > > So EDKII doesn't have that capability, FSBClock is a build time value > and can't be changed at run time. But OVMF (on KVM or HVM) doesn't use > that value at all, it uses the ACPI timer instead. But after your series both PVH and HVM will use the lapic timer instead of the ACPI timer, and thus rely on the value of FSBClock? > We could try to find a better way to get time in OvmfXen without > hardcoding FSBClock, but maybe in a follow-up. Yes please. As said above lapic frequency is not part of the ABI, so if we need to use it like that APIC_BUS_CYCLE_NS (currently in vlapic.h) would have to be moved to a public header. Thanks, Roger.
On 08/08/19 15:44, Roger Pau Monné wrote: > On Thu, Aug 08, 2019 at 02:28:32PM +0100, Anthony PERARD wrote: >> On Wed, Aug 07, 2019 at 05:54:51PM +0200, Roger Pau Monné wrote: >>> On Mon, Jul 29, 2019 at 04:39:38PM +0100, Anthony PERARD wrote: >>>> PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib >>>> implementation. It will also be used by XenTimerDxe. Override >>>> PcdFSBClock to match Xen vLAPIC timer frequency. >>> >>> I'm kind of surprised that his is not automatically detected? >>> >>> Is it a bug in Xen or just always hardcoded on OVMF? >> >> It's hardcoded. Why would you need auto detection when you always run on >> the same machine ;-). > > I don't think that's part of the HVM/PVH ABI in any way, and if you > hardcode it in OVMF it would prevent Xen from changing the frequency > in the future if such necessity arises. We should try to avoid painting > ourselves into a corner when possible. > > Doesn't OVMF have a way to get this from the hardware itself? It might be possible to change the PCDs access method in the DSC file to "dynamic", and then set it dynamically in XenPlatformPei. That should work fine if only the DXE phase relies on the PCD. However, if PEIMs (other than XenPlatformPei) consume the PCD too, then the ordering (between set/get) might not be trivial to ensure. This kind of problem sometimes requries separate library instances for SEC/PEI/DXE. Thanks Laszlo
On Thu, Aug 08, 2019 at 05:18:15PM +0200, Roger Pau Monné wrote: > On Thu, Aug 08, 2019 at 03:26:41PM +0100, Anthony PERARD wrote: > > So EDKII doesn't have that capability, FSBClock is a build time value > > and can't be changed at run time. But OVMF (on KVM or HVM) doesn't use > > that value at all, it uses the ACPI timer instead. > > But after your series both PVH and HVM will use the lapic timer > instead of the ACPI timer, and thus rely on the value of FSBClock? Short answer, Yes. Longuer answer, after the series is applied, there will be a new platform, "OvmfXen" which will be for both Xen PVH and Xen HVM, but the OVMF that we know (OvmfPkgX64 that xen.git builds) will still be capable of running on Xen HVM for a short while and will still use the ACPI timer.
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc index 22970eda5d..477d8c76a1 100644 --- a/OvmfPkg/OvmfXen.dsc +++ b/OvmfPkg/OvmfXen.dsc @@ -439,6 +439,9 @@ [PcdsFixedAtBuild] # Point to the MdeModulePkg/Application/UiApp/UiApp.inf gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 } + ## Xen vlapic's frequence is 100 MHz + gEfiMdePkgTokenSpaceGuid.PcdFSBClock|100000000 + ################################################################################ # # Pcd Dynamic Section - list of all EDK II PCD Entries defined by this Platform