From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752154AbdEQAPa (ORCPT ); Tue, 16 May 2017 20:15:30 -0400 Received: from mail-pf0-f194.google.com ([209.85.192.194]:36365 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750949AbdEQAP2 (ORCPT ); Tue, 16 May 2017 20:15:28 -0400 Reply-To: pgnet.dev@gmail.com Subject: Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS? To: "Austin S. Hemmelgarn" , Valentin Vidic Cc: Andrew Cooper , Randy Dunlap , "linux-kernel@vger.kernel.org" , Clemens Ladisch , xen-devel@lists.xenproject.org References: <2c84903a-ab24-a073-378b-82fe6052e6ac@infradead.org> <927a6245-ae8b-ff4b-d668-a819b8351152@citrix.com> <34c505d9-9dc6-8982-4875-74dedfc5e0d1@gmail.com> <20170513202811.j5mhumhvow3gadms@gavran.carpriv.carnet.hr> <20170513213215.wxkskhyvbu7rz7n7@gavran.carpriv.carnet.hr> <20170513221536.bmijpvmv47pab75c@gavran.carpriv.carnet.hr> <5c0c01ae-775f-55b0-934e-90f81eae8ea3@gmail.com> <932d20ce-601d-cb56-73bc-cc2201a85da0@gmail.com> From: PGNet Dev Message-ID: <54faf2e8-4d1f-cf16-204a-8e5900e69f13@gmail.com> Date: Tue, 16 May 2017 17:15:24 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:53.0) Gecko/20100101 Thunderbird/53.0 MIME-Version: 1.0 In-Reply-To: <932d20ce-601d-cb56-73bc-cc2201a85da0@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org (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.