[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 0 of 5] PV on HVM Xen
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. 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. It's not like we can't move the hook earlier in the future if that turns our to be unavoidably necessary. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |