Re: [Xen-devel] [PATCHv1] x86: rtc_cmos platform device requires legacy irqs

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 12/04/2015 10:52 AM, Vitaly Kuznetsov wrote:
> Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> writes:
>
> > On 12/04/2015 10:24 AM, David Vrabel wrote:
> > > On 04/12/15 14:06, David Vrabel wrote:
> > > > On 03/12/15 10:43, David Vrabel wrote:
> > > > > Adding the rtc platform device when there are no legacy irqs (no
> > > > > legacy PIC) causes a conflict with other devices that end up using the
> > > > > same irq number.
> > > > An alternative is to remove the rtc_cmos platform device in Xen PV
> > > > guests.
> > > >
> > > > Any preference on how this regression should be fixed?
> > > >
> > > > David
> > > >
> > > > 8<--------------------------
> > > > x86: Xen PV guests don't have the rtc_cmos platform device
> > > [...]
> > > > --- 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 (xen_pv_domain())
> > > > +               return -ENODEV;
> > > > +
> > > Note there's a missing include that breaks !XEN builds.
> > We could also use paravirt_enable() here which will probably cover
> > HVMlite case as well. (Until we start turning on and off various
> > HVMlite features).
> Would it make sense to create a new abstraction, e.g. 'rtc_available' in
> struct hypervisor_x86?
We could do this but since this fine-grained feature enabling is still 
way off it may be worth waiting until we actually get to this.
Besides, it would probably be something like if (paravirt_enabled() && 
!rtc_available) so for now having just the first term should suffice.
-boris

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