On 12/04/2015 10:52 AM, Vitaly Kuznetsov wrote:
Boris Ostrovsky <boris.ostrov...@oracle.com> 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@lists.xen.org
http://lists.xen.org/xen-devel
