Re: [Xen-devel] [PATCH] x86: Xen PV guests don't have the rtc_cmos platform device

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 12/09/2015 10:27 AM, Jan Beulich wrote:
> > > > On 09.12.15 at 16:15, <boris.ostrovsky@xxxxxxxxxx> 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@xxxxxxxxxx> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel