This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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.


Xen-devel mailing list