Re: [edk2-devel] [PATCH V2 0/2] Rename XenTimerDxe to LocalApicTimerDxe

["Yao, Jiewen" <jiewen.yao@intel.com>]

We can state, this driver is to support fixed frequency.
If a real platform happens to have fixed frequency, then it can be used.

gEfiMdePkgTokenSpaceGuid.PcdFSBClock  is defined in MdePkg.
The consumer need set PcdFSBClock. 

I don't see a need to bind to OVMF.

Thank you
Yao Jiewen

> -----Original Message-----
> From: Gerd Hoffmann <kraxel@redhat.com>
> Sent: Tuesday, November 2, 2021 5:59 PM
> To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>
> Cc: Xu, Min M <min.m.xu@intel.com>; Ard Biesheuvel
> <ardb+tianocore@kernel.org>; Justen, Jordan L <jordan.l.justen@intel.com>;
> Brijesh Singh <brijesh.singh@amd.com>; Erdem Aktas
> <erdemaktas@google.com>; James Bottomley <jejb@linux.ibm.com>; Tom
> Lendacky <thomas.lendacky@amd.com>
> Subject: Re: [edk2-devel] [PATCH V2 0/2] Rename XenTimerDxe to
> LocalApicTimerDxe
> 
>   Hi,
> 
> > Do you think it should so generic that it can remove OvmfPkg dependency and
> be moved to UefiCpuPkg?
> 
> It's not fully standalone, the driver needs to know the lapic frequency
> (that is the reason why PcdFSBClock exists).
> 
> For KVM this is easy, the lapic uses a fixed frequency so it can simply
> be set in the .dsc file.
> 
> For Xen the lapic frequency is the same as the tsc frequency, so the xen
> code (platform init I think) goes figure the tsc freq and sets
> PcdFSBClock accordingly.
> 
> So, when you want use the driver elsewhere you need to fill that gap,
> and there is little reason to go that extra mile because on physical
> hardware you have other options like using the hpet timer.
> 
> [ qemu supports hpet emulation but it is disabled by default for
>   performance reasons, other timers have less virtualization
>   overhead. ]
> 
> I'd suggest to keep it in OvmfPkg.
> 
> take care,
>   Gerd