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.
next prev 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