Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

["Austin S. Hemmelgarn" <ahferroin7@xxxxxxxxx>]

On 2017-05-13 19:17, PGNet Dev wrote:
> On 5/13/17 3:15 PM, Valentin Vidic wrote:
> > Try booting without 'hpet=force,verbose clocksource=hpet' and it should
> > select xen by default:
> Nope. Well, not quite ...
>
> With both
>
>         'hpet=force,verbose clocksource=hpet'
>
> removed, I end up with
>
>         cat /sys/devices/system/clocksource/clocksource0/available_clocksource
>                 tsc xen
>         cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>                 tsc
>
> But with
>
>         clocksource=xen
>
> *explicitly* added
>
>         cat /sys/devices/system/clocksource/clocksource0/available_clocksource
>                 tsc xen
>         cat /sys/devices/system/clocksource/clocksource0/current_clocksourcexen
>                 xen
>
> and in *console*, NOT dmesg, output,
>
>         grep -i hpet tmp.txt
>                 (XEN) ACPI: HPET 9E8298F8, 0038 (r1 SUPERM SMCI--MB  1072009 
> AMI.        5)
>                 (XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
>                 (XEN) [VT-D] MSI HPET: 0000:f0:0f.0
>                 (XEN) Platform timer is 14.318MHz HPET
>                 [    0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM 
> SMCI--MB 01072009 AMI. 000000
>                 [    0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
>                 [    0.000000] ACPI: HPET 0x000000009E8298F8 000038 (v01 SUPERM 
> SMCI--MB 01072009 AMI. 000000
>                 [    0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
>                 [    8.515245] hpet_acpi_add: no address or irqs in _CRS
>                 [    8.515245] hpet_acpi_add: no address or irqs in _CRS
>                 (XEN) [2017-05-13 23:04:27] HVM1 save: HPET
>
>
>
> and
>
>         dmesg | grep -i clocksource | grep -v line:
>                 [    0.000000] clocksource: refined-jiffies: mask: 0xffffffff 
> max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
>                 [    0.004000] clocksource: xen: mask: 0xffffffffffffffff 
> max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
>                 [    0.375709] clocksource: jiffies: mask: 0xffffffff 
> max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
>                 [    4.656634] clocksource: Switched to clocksource xen
>                 [    8.912897] clocksource: tsc: mask: 0xffffffffffffffff 
> max_cycles: 0x2c94dffea94, max_idle_ns: 440795361700 ns
>
> jiffies, now? hm. no idea where that came from. and why the 'tsc' ?
>
> So I'm still unclear -- is this^ now, correctly "all" using MSI/HPET?
That depends on what you mean by everything correctly using the HPET. 
Using clocksource=xen (or autoselecting it) will cause the kernel to get 
timing info from Xen.  If you're running as a guest, this is absolutely 
what you want (unless you're using HVM), and with possible limited and 
extremely specific exceptions, this is almost certainly what you want in 
Domain-0 as well.  Given that Xen is using the HPEt for timing itself, 
using clocksource=xen will result in Linux _indirectly_ using the HPET 
through Xen without involving the HPET driver (in essence, Xen is your 
HPET driver in this situation), which will get you essentially the same 
precision that you would get by using the HPET directly.
So, if you just want the precision offered by the HPET, then yes, you 
are getting the same thing through the Xen clocksource.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel