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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <54faf2e8-4d1f-cf16-204a-8e5900e69f13@gmail.com>
Date:   Tue, 16 May 2017 17:15:24 -0700
From:   PGNet Dev <pgnet.dev@...il.com>
To:     "Austin S. Hemmelgarn" <ahferroin7@...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?

(apologies re: the empty 'double tap' :-/ )

On 5/14/17 8:39 AM, Andrew Cooper wrote:
>> So I'm still unclear -- is this^ now, correctly "all" using MSI/HPET?
> 
> What are you trying to achieve?  It is still not clear despite all on
> this thread.
> 
> The Linux HEPT error messages are non-ideal, but there is no way dom0
> will ever be able to use clocksource=hpet when running under Xen.

What I'm trying to achieve is to

	(a) understand, in general
	(b) correctly implement HPET usage in Xen
&
	(c) understand &, as needed, remediate the warnings/error message that seem(ed) to be associated

I.e. -- what exactly needs be done, and what should be the observable results, when "using" HPET with Xen.  It's simply not obvious from the docs.

The docs here,

	https://wiki.xen.org/wiki/Xen_power_management

are ... somewhat challenging:

	"By far Xen3.4 supports PIT/HPET as the broadcast source.
	...
	HPET as broadcast timer source (clocksource) =
	...
	HPET can delivery timely wakeup event to CPUs sleep in deep C-states with negligible overhead, as stated earlier. But HPET mode being used does make some differences to worthy of our noting:

	    If h/w supports per-channel MSI delivery mode (intr via FSB), it's the best broadcast mechanism known so far.
	...
	"

??

OTOH, this comment:

On 5/15/17 11:06 AM, Austin S. Hemmelgarn wrote:
> 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.

Is legible, understandable & helpfully informative. (Thanks, Austin! Valentin's comments helped as well.)

'tho further detail on common &/or "limited and extremely specific exceptions" use-cases of PVH, HVM, PVHVM & HVM2 will be useful, I'd heartily recommend that some version of Austin's comment be added to the docs/wiki as a nice doc-step forward.