mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: PGNet Dev <pgnet.dev@gmail.com>
To: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>,
	Valentin Vidic <Valentin.Vidic@CARNet.hr>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Clemens Ladisch <clemens@ladisch.de>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?
Date: Tue, 16 May 2017 17:15:24 -0700	[thread overview]
Message-ID: <54faf2e8-4d1f-cf16-204a-8e5900e69f13@gmail.com> (raw)
In-Reply-To: <932d20ce-601d-cb56-73bc-cc2201a85da0@gmail.com>

(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.

  parent reply	other threads:[~2017-05-17  0:15 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-13  2:30 PGNet Dev
2017-05-13 17:41 ` Randy Dunlap
2017-05-13 18:26   ` PGNet Dev
2017-05-13 19:28     ` Randy Dunlap
2017-05-13 19:38       ` [Xen-devel] " Andrew Cooper
2017-05-13 19:49         ` PGNet Dev
2017-05-13 19:59           ` Andrew Cooper
2017-05-13 20:05             ` PGNet Dev
2017-05-13 20:16               ` Andrew Cooper
2017-05-13 21:07                 ` PGNet Dev
2017-05-14 17:13                 ` Juergen Gross
2017-05-13 20:28               ` Valentin Vidic
2017-05-13 21:06                 ` PGNet Dev
2017-05-13 21:32                   ` Valentin Vidic
2017-05-13 21:58                     ` PGNet Dev
2017-05-13 22:15                       ` Valentin Vidic
2017-05-13 23:17                         ` PGNet Dev
2017-05-14 15:39                           ` Andrew Cooper
2017-05-14 17:41                             ` Randy Dunlap
2017-05-15 18:06                           ` Austin S. Hemmelgarn
2017-05-17  0:12                             ` PGNet Dev
2017-05-17  0:15                             ` PGNet Dev [this message]
2017-05-13 19:45   ` Clemens Ladisch
2017-05-13 19:52     ` PGNet Dev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54faf2e8-4d1f-cf16-204a-8e5900e69f13@gmail.com \
    --to=pgnet.dev@gmail.com \
    --cc=Valentin.Vidic@CARNet.hr \
    --cc=ahferroin7@gmail.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=clemens@ladisch.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome