Re: [PATCH 0 of 5] PV on HVM Xen

[Sheng Yang <sheng@linux.intel.com>]

On Thursday 18 March 2010 02:20:28 Ian Campbell wrote:
> On Wed, 2010-03-17 at 15:17 +0000, Stefano Stabellini wrote:
> > On Wed, 17 Mar 2010, Sheng Yang wrote:
> > > Seem not get enough update...
> > >
> > > OK, a new flag, adjustment in Xen. Right?
> >
> > Yes, a new flag to signal the presence of a reliable clocksource on HVM;
> > adjustments in Xen to make it work (keep in mind that my patch fix the
> > problem only when tsc_mode==2 and we need to support tsc_mode==1 too).
> >
> > On the other hand we agreed that we don't need XEN_HVM_PV_EVTCHN_ENABLED
> > and CONFIG_XEN_HVM_PV anymore.
> > We probably don't need XEN_HVM_PV too for the moment, we might introduce
> > it in the future when we actually add code that doesn't work on 32 bit.
> >
> > Finally I would still like the call to xen_guest_init to be moved
> > afterwards: if we move it after kvm_guest_init we can be pretty sure
> > that upstream is going to accept it. Besides ACPI is currently working
> > with your patch series applied, when and if we break ACPI we'll worry
> > about it.
> >
> > Jeremy, Ian, does this seem reasonable to you? The last point in
> > particular?  If you are sure that upstream will accept a hook in setup.c
> > anyway I am ready to drop this.
> 
> I think that if we can we should avoid disabling ACPI, and if we don't
> need to do that then I'm not sure we need the Xen initialisation point
> to be all that early. 

Yes, the issue is ACPI. 

> I would think that the location of the KVM init
> point is likely to be a good choice for Xen as well, in the absence of
> other considerations there's a pretty strong argument for keeping these
> virtualisation entry points in the same place.

But I don't think this argument is strong enough...

Look back to setup_arch(), you can see this:

Line		Function
696		vmi_init()
794		vmi_activate()
966		kvmclock_init()
1008		kvm_guest_init()

The code is already sparse... Each function have different requirement(before 
xxx, or after xxx), so it is quite understandable...

-- 
regards
Yang, Sheng

> 
> It's not like we can't move the hook earlier in the future if that turns
> our to be unavoidably necessary.
> 
> Ian.
>