linux-kernel - Re: [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAB=NE6W3gnH8_cFE4q2QStm-KXn+TtEB_sZHWoSD5ZF7cqD04A@mail.gmail.com>
Date:	Thu, 7 Apr 2016 23:56:31 -0700
From:	"Luis R. Rodriguez" <mcgrof@...nel.org>
To:	Juergen Gross <jgross@...e.com>
Cc:	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Borislav Petkov <bp@...en8.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Rusty Russell <rusty@...tcorp.com.au>, X86 ML <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	David Vrabel <david.vrabel@...rix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	lguest@...ts.ozlabs.org,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Joey Lee <jlee@...e.com>, Gary Lin <glin@...e.com>,
	Matt Fleming <matt@...eblueprint.co.uk>,
	Andrew Cooper <andrew.cooper3@...rix.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Len Brown <lenb@...nel.org>,
	"Moore, Robert" <robert.moore@...el.com>,
	Lv Zheng <lv.zheng@...el.com>, Toshi Kani <toshi.kani@...com>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	kozerkov@...allels.com, Josh Triplett <josh@...htriplett.org>,
	Joerg Roedel <joro@...tes.org>
Subject: Re: [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with
 platform legacy quirk

On Thu, Apr 7, 2016 at 11:38 PM, Juergen Gross <jgross@...e.com> wrote:
> On 08/04/16 08:29, Luis R. Rodriguez wrote:
>> On Thu, Apr 7, 2016 at 10:18 PM, Juergen Gross <jgross@...e.com> wrote:
>>> On 08/04/16 02:32, Luis R. Rodriguez wrote:
>>>> This highlights a semantic gap issue. From a quick cursory review, I think
>>>> we can address this temporarily by just using a check:
>>>>
>>>> void __init x86_early_init_platform_quirks(void)
>>>> {
>>>>       x86_platform.legacy.rtc = 1;
>>>>
>>>>       switch (boot_params.hdr.hardware_subarch) {
>>>>       case X86_SUBARCH_XEN:
>>>>       case X86_SUBARCH_LGUEST:
>>>>       case X86_SUBARCH_INTEL_MID:
>>>> -             x86_platform.legacy.rtc = 0;
>>>> +             if (x86_init.mpparse.get_smp_config != x86_init_uint_noop)
>>>> +                     x86_platform.legacy.rtc = 0;
>>>
>>> No! Why don't you just use the explicit test xen_initial_domain() ?
>>
>> Because we don't want to sprinkle Xen specific code outside of Xen
>> code. What do you think about the second possibility I listed?
>> Otherwise, any other ideas?
>
> Don't try to guess.

I can only do that given there is nothing at all to tell me what to
expect here with regards to RTC on Xen guest, if there is some
documentation that could help with that please let me know.

> In case you don't want to inject Xen internals here, just call a Xen
> function to either return the correct value, or to set all structure
> elements correctly.

I like the later as an option, in case there are further hardware
subarch specific quirks which require internal logistics. What do
others think?

> Thinking more about it: why not do that for all the subarchs?

I originally had went with that approach, but Ingo made the point that
it would be best to instead move all quirk settings into one place.
That lets a reader easily tell what is going on in one place, it also
compartmentalizes the hardware subarch uses.

> You'd
> have the specific settings where they belong: in a subarch specific
> source. Just do the default settings in x86_early_init_platform_quirks()
> and let the subarch functions set the non-default values.

This is a rather different approach than what I had originally tried.
Bike shed thing -- someone just has to decide.

Left up to me, I kind of really like centralizing the quirk settings
in one place approach as it means a reader can easily tell what's
going on regardless of platform in one place for odd settings. I
prefer this given that we *already* have the semantics over hardware
subarch in a generalized fashion. We *do not* have semantics for dom0
Vs domU -- if such a notion is generic to other virtualization
environments it deserves consideration to new semantics to deal with
that, otherwise the callback for handling further quirks is best, but
I'd also highly discourage such callback to be used.

 Luis