[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <932d20ce-601d-cb56-73bc-cc2201a85da0@gmail.com>
Date: Mon, 15 May 2017 14:06:32 -0400
From: "Austin S. Hemmelgarn" <ahferroin7@...il.com>
To: pgnet.dev@...il.com, Valentin Vidic <Valentin.Vidic@...Net.hr>
Cc: Andrew Cooper <andrew.cooper3@...rix.com>,
Randy Dunlap <rdunlap@...radead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Clemens Ladisch <clemens@...isch.de>,
xen-devel@...ts.xenproject.org
Subject: Re: [Xen-devel] HPET enabled in BIOS, not presented as
available_clocksource -- config, kernel code, &/or BIOS?
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.
Powered by blists - more mailing lists