Messages in this thread | | | Date | Mon, 15 Mar 2010 12:04:16 +0000 | From | Stefano Stabellini <> | Subject | Re: [Xen-devel] [PATCH][v9 4/6] xen/hvm: Xen PV extension of HVM initialization |
| |
On Mon, 15 Mar 2010, Sheng Yang wrote: > > > +#ifdef CONFIG_XEN_HVM_PV > > > + > > > +#define XEN_HVM_PV_CLOCK_ENABLED (1u<< 0) > > > > Why is this flag needed? As far as I understand it, there's no real > > underlying hypervisor change needed to make HVM access to pv clock > > possible; its just a field in the shared_info's vcpu struct after all. > > Even if you enable this feature unconditionally, the user can still > > control whether the Xen clocksource is used with the "clocksource=" > > kernel command-line parameter. > > 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.
> > Also, there's nothing about this which is 64-bit specific is there? > > 64 bit things are mostly evtchn/interrupt related. I think no such limit here. > But I think it's better to do it step by step, so leave it after evtchn > solution settled. >
Do you mean write generic code now, then introduce the 64 bit limitation later? Or the other way around? I don't have a strong opinion here so I am OK with both approaches, but I would prefer to add the limitation later (maybe we'll be able to make it work on 32 bit too...).
| |