linux-kernel - Re: [Xen-devel] [PATCH] x86: Xen PV guests don't have the rtc

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]

Date:	Wed, 9 Dec 2015 13:18:57 -0500
From:	Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:	Jan Beulich <JBeulich@...e.com>,
	Sander Eikelenboom <linux@...elenboom.it>
Cc:	David Vrabel <david.vrabel@...rix.com>, x86@...nel.org,
	tglx@...utronix.de, xen-devel@...ts.xenproject.org,
	mingo@...hat.com, vkuznets@...hat.com,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org, hpa@...or.com
Subject: Re: [Xen-devel] [PATCH] x86: Xen PV guests don't have the rtc_cmos
 platform device

On 12/09/2015 10:27 AM, Jan Beulich wrote:
>>>> On 09.12.15 at 16:15, <boris.ostrovsky@...cle.com> wrote:
>> On 12/09/2015 10:00 AM, Sander Eikelenboom wrote:
>>> On 2015-12-09 15:42, Jan Beulich wrote:
>>>>>>> On 09.12.15 at 15:32, <boris.ostrovsky@...cle.com> wrote:
>>>>> --- a/arch/x86/kernel/rtc.c
>>>>> +++ b/arch/x86/kernel/rtc.c
>>>>> @@ -200,6 +200,9 @@ static __init int add_rtc_cmos(void)
>>>>>       }
>>>>>   #endif
>>>>>
>>>>> +    if (paravirt_enabled())
>>>>> +        return -ENODEV;
>>>> What about Xen Dom0?
>>>>
>>>> Jan
>>> Checked that in my testing and that still worked:
>>> [   16.733837] rtc_cmos 00:02: RTC can wake from S4
>>> [   16.734030] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
>>> [   16.734087] rtc_cmos 00:02: alarms up to one month, y3k, 114 bytes
>>> nvram
>>> [   17.760329] rtc_cmos 00:02: setting system clock to 2015-12-09
>>> 08:43:48 UTC (1449650628)
>>>
>>> and /dev/rtc and /dev/rtc0 both exist.
>>>
>>> But i don't know the nitty gritty details about why ...
>>
>> That's because it is discovered by ACPI earlier. I don't know though
>> whether we can always assume this will be the case.
> I don't think we should - Dom0 should (device-wise) behave just
> like a native kernel.

So maybe then this is the case for having a feature flag (probably in 
pv_info) that marks which features are paravirtualized.

Vitaly suggested it earlier but I thought we won't have use for it until 
we get to HVMlite with variable set of fetures.

-boris

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/