From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@protonmail.com header.s=default header.b=gw28xBMC; spf=pass (domain: protonmail.com, ip: 185.70.40.132, mailfrom: vit9696@protonmail.com) Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by groups.io with SMTP; Thu, 15 Aug 2019 14:10:54 -0700 Date: Thu, 15 Aug 2019 21:10:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1565903451; bh=GmLgLFQFDqouZmE0Cv8PZ0J8zMCohR2tQfQEqaRRSM8=; h=Date:To:From:Reply-To:Subject:Feedback-ID:From; b=gw28xBMCfr5vbdetNVzAaf71QaRiln1UVWNtKvuqtleHbvMFuhLWbzQbsIGT75lfC F025/FsChjETUFXjmbZCy+kDKC66VeBgfwYn3YL2lkSRbEvTxmow/nTkEkYmJI+AZn WOb5F44sj4s9t00GBrBvfsAiLeffm/3u19BUp1Aw= To: devel@edk2.groups.io, jiewen.yao@intel.com From: "Vitaly Cheptsov" Reply-To: "vit9696@protonmail.com" Subject: Determining TSC frequency programmatically Message-ID: <8EC14D0D-DFA5-412D-A4E1-4D641576D58E@protonmail.com> Feedback-ID: p9QuX-L1wMgUm6nrSvNrf8juLupNs0VSnzXGVXuYDxlEahFdWtaedWDMB9zpwGDklGt7kzs1-RBc0cqz327Gcg==:Ext:ProtonMail MIME-Version: 1.0 X-Spam-Status: No, score=-0.7 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,FREEMAIL_REPLYTO_END_DIGIT,HTML_MESSAGE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.protonmail.ch X-Groupsio-MsgNum: 45750 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha256; boundary="---------------------c890be53b076605aba0e9fc24adec3c8"; charset=UTF-8 -----------------------c890be53b076605aba0e9fc24adec3c8 Content-Type: multipart/alternative; boundary="Apple-Mail=_B332BD48-DB73-46F5-B372-F01600D58B04" Date: Fri, 16 Aug 2019 00:10:42 +0300 From: "vit9696@protonmail.com" Message-Id: <8EC14D0D-DFA5-412D-A4E1-4D641576D58E@protonmail.com> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Determining TSC frequency programmatically To: devel@edk2.groups.io, "Kuo, Donald" , "Kinney, Michael D" , "Dong, Eric" , "Ni, Ray" , jiewen.yao@intel.com X-Mailer: Apple Mail (2.3445.104.11) --Apple-Mail=_B332BD48-DB73-46F5-B372-F01600D58B04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, I initially raised this question in a new TimerLib patch[1], but as the dis= cussion was getting more distracted, I decided to create a separate thread = in hopes new people could join. The issue is that our UEFI bootloader needs to obtain TSC frequency to pass= it to our specialised operating system that uses TSC for scheduling on x86= . For a while we went with ACPI power management timer to measure the frequen= cy, but as modern Intel CPUs support CPUID 15H leaf (CPUID_TIME_STAMP_COUNT= ER) we try to use where possible for better accuracy. The issue with this C= PUID leaf is that the crystal clock frequency returned in ECX register is o= ptional and therefore can be 0. Intel SDM suggests to use a static value in= this case[2], but it is completely opaque on how to match the running CPU = with its static value from SDM. Initially we went with CPUID model checking, but this failed badly for Xeon= Scalable and Xeon W, as they share the CPUID (06_55H) but have different c= rystal clock frequencies (25 MHz vs 24 MHz accordingly). Donald Kuo gave a = good hint in the previous thread that client CPUs usually get 24 MHz crysta= l clock, server CPUs have 25, and Atoms have 19.2. This, however, does not = make the situation easier as we do not see a way to determine CPU vertical = segment without e.g. parsing the CPUID brand string. Apparently, we are not alone, and different open-source operating systems h= ave different workarounds to this issue. For example, Linux kernel went wit= h using marketing frequency from CPUID 16H leaf (CPUID_PROCESSOR_FREQUENCY)= [3], and BSD flavours fallback to older methods when neither crystal clock = frequency can be obtained through CPUID 15H, nor unambiguous CPUID models e= xist to be able to use static values. Another issue we see with EDK II TimerLib implementations for x86 is that t= hey are very model specific. As Michael Kinney said, the situation is not a= problem when you use TimerLib for BSP bringup, as you already know the CPU= family you target, however, it is not great for other uses, although they = may be discouraged. In our opinion, regardless of the use, this approach ha= s a number of design issues. All modern Intel x86 CPUs have virtual TSC counter that has fixed frequency= . In fact, this is true for most, if not all, modern x86 CPUs by other vend= ors as well. This makes us believe that EDK II should have generic TscTimer= Lib for x86, which will work anywhere when given valid TSC frequency, and T= scFrequencyLib, which would determine TSC frequency in a vendor-specific me= thod. Ideally there exists GenericTscFrequencyLib that can do this for a wi= de majority of CPUs through different methods at runtime, including CPUID 1= 5H, ACPI power management, vendor-specific extensions, etc. To summarise: - We need to know how to match current running CPU with its crystal clock f= requency when CPUID 15H reports 0 ECX. - We would like to suggest to split TSC-based TimerLib in two libraries: ge= neric with timer implementation and platform-specific with TSC frequency di= scovery. - We wonder whether a generic vendor-supported TSC frequency discovery libr= ary working on a wide range of CPUs is feasible to have in EDK II mainline. Best regards, Vitaly [1] https://edk2.groups.io/g/devel/topic/patch_ueficpupkg_adding_a/32839184= ?p=3D,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,32839184 [PATCH] UefiCpuPkg: Adding a new TSC library by using CPUID(0x15) TSC l= eaf [2] 18.7.3 Determining the Processor Base Frequency Table 18-75. Nominal Core Crystal Clock Frequency [3] https://lore.kernel.org/lkml/20190509055417.13152-1-drake@endlessm.com/= --Apple-Mail=_B332BD48-DB73-46F5-B372-F01600D58B04 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello,
<= br class=3D"">
I initially raised this question in a n= ew TimerLib patch[1], but as the discussion was getting more distracted, I = decided to create a separate thread in hopes new people could join.

The issue is that our UE= FI bootloader needs to obtain TSC frequency to pass it to our specialised o= perating system that uses TSC for scheduling on x86.
<= br class=3D"">
For a while we went with ACPI power man= agement timer to measure the frequency, but as modern Intel CPUs support CP= UID 15H leaf (CPUID_TIME_STAMP_COUNTER) we try to use where possible for be= tter accuracy. The issue with this CPUID leaf is that the crystal clock fre= quency returned in ECX register is optional and therefore can be 0. Intel S= DM suggests to use a static value in this case[2], but it is completely opa= que on how to match the running CPU with its static value from SDM.

Initially we went with C= PUID model checking, but this failed badly for Xeon Scalable and Xeon W, as= they share the CPUID (06_55H) but have different crystal clock frequencies= (25 MHz vs 24 MHz accordingly). Donald Kuo gave a good hint in the previou= s thread that client CPUs usually get 24 MHz crystal clock, server CPUs hav= e 25, and Atoms have 19.2. This, however, does not make the situation easie= r as we do not see a way to determine CPU vertical segment without e.g. par= sing the CPUID brand string.

Apparently, we are not alone, and different open-source operati= ng systems have different workarounds to this issue. For example, Linux ker= nel went with using marketing frequency from CPUID 16H leaf (CPUID_PROCESSO= R_FREQUENCY)[3], and BSD flavours fallback to older methods when neither cr= ystal clock frequency can be obtained through CPUID 15H, nor unambiguous CP= UID models exist to be able to use static values.

Another issue we see with EDK II TimerLib = implementations for x86 is that they are very model specific. As Michael Ki= nney said, the situation is not a problem when you use TimerLib for BSP bri= ngup, as you already know the CPU family you target, however, it is not gre= at for other uses, although they may be discouraged. In our opinion, regard= less of the use, this approach has a number of design issues.

All modern Intel x86 CPUs have= virtual TSC counter that has fixed frequency. In fact, this is true for mo= st, if not all, modern x86 CPUs by other vendors as well. This makes us bel= ieve that EDK II should have generic TscTimerLib for x86, which will work a= nywhere when given valid TSC frequency, and TscFrequencyLib, which would de= termine TSC frequency in a vendor-specific method. Ideally there exists Gen= ericTscFrequencyLib that can do this for a wide majority of CPUs through di= fferent methods at runtime, including CPUID 15H, ACPI power management, ven= dor-specific extensions, etc.

To summarise:
- We need to know how to ma= tch current running CPU with its crystal clock frequency when CPUID 15H rep= orts 0 ECX.
- We would like to suggest to split TSC-ba= sed TimerLib in two libraries: generic with timer implementation and platfo= rm-specific with TSC frequency discovery.
- We wonder = whether a generic vendor-supported TSC frequency discovery library working = on a wide range of CPUs is feasible to have in EDK II mainline.

Best regards,
Vitaly

[1]=  https://edk2.groups.io/g/devel/topic/patch_ueficpupkg_adding_a/3283= 9184?p=3D,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,32839184
    [PATCH] UefiCpuPkg: Adding a new TSC library by= using CPUID(0x15) TSC leaf
[2] 18.7.3 Determinin= g the Processor Base Frequency
Table 18-75. Nominal Co= re Crystal Clock Frequency
[3] https://lore.kernel.org/lkml/20190509055417.1= 3152-1-drake@endlessm.com/

--Apple-Mail=_B332BD48-DB73-46F5-B372-F01600D58B04-- -----------------------c890be53b076605aba0e9fc24adec3c8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsBmBAEBCAAQBQJdVcpTCRBPsoxt7Hy0xQAKCRBPsoxt7Hy0xZYBCAA56y+i 49RVGxxu77LKUcwV2oN3vetkt0zOlQW/3Zm0uDgrOkdEL11MGByDNqi+OEDL t8C3cCbqQONKp2xoTUCgwBKz23rNB5muITlHSkAN7YoSfzPZaxdK+UCs+xH6 OHYW5qOswQSmh5rhnLyOsahxpSzoLHCL4fphYx0B8RGvA/XplcnB5xu2047B AL7c1N/4pUEiHVrMIJ8Cl+bGjb7I9Zo86rVFhjRHD0iTpa65x9kFLDVWqNnq QTd1Pki5FgnCZIaOLwSRtCaMpd3hpZzTTyfAWXFdfi0LazYx1VkTJZBFCSAX Ky4xMTpRx6dl7jeKkERYIwgSinyR6WthrcqS =qh3z -----END PGP SIGNATURE----- -----------------------c890be53b076605aba0e9fc24adec3c8--