Messages in this thread | | | Date | Tue, 16 Mar 2010 10:12:10 -0700 | From | Jeremy Fitzhardinge <> | Subject | Re: [Xen-devel] [PATCH][v9 4/6] xen/hvm: Xen PV extension of HVM initialization |
| |
On 03/15/2010 06:51 PM, Sheng Yang wrote: > On Tuesday 16 March 2010 06:59:58 Jeremy Fitzhardinge wrote: > >> On 03/15/2010 05:04 AM, Stefano Stabellini wrote: >> >>>> But we should make sure Xen have ability to support such kind of >>>> operation. The CPUID would show if Xen have such ability, and if it >>>> does, the feature would be enabled unconditionally. Guest kernel always >>>> enable all features it can do unconditionally, but Xen should offer the >>>> support for them. >>>> >>> In my opinion once the guest knows that is running on Xen HVM (that is >>> from xen_cpuid_base() or xen_para_available()) it should assume >>> that the pv clocksource is available, therefore XEN_HVM_PV_CLOCK_ENABLED >>> should not be needed. >>> In other words the mere presence of Xen should imply >>> XEN_HVM_PV_CLOCK_ENABLED. >>> >> The only reason why we wouldn't want to do this is if we want to >> withdraw this feature at some point in the future. We're stuck with it >> indefinitely for PV, but I don't know if that's necessarily going to be >> the case for HVM. On the other hand, if other - better - mechanisms >> become available, we can give them their own clocksource driver with a >> higher priority than the Xen pvclock one, and users can still select >> clocksources on the kernel command line. >> > So you think about adding a new XENFEAT? >
I think that's a bit arbitrary. If we need a new vcpuop to make it work properly anyway (set tsc offset), then the presence of that should be a good indicator. In other words, make it depend on its actual fixed pre-reqs, rather than a specific flag for the feature.
>> Seems like making it work for both 32 and 64-bit is the easiest thing to >> do. >> > If it is, it should be fine. But I had encountered some issues on 32 bits. >
What kinds of issues?
J
| |