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

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0 of 5] PV on HVM Xen
From: Sheng Yang <sheng@xxxxxxxxxxxxxxx>
Date: Thu, 18 Mar 2010 09:42:25 +0800
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Delivery-date: Wed, 17 Mar 2010 18:43:00 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1268850028.10129.36012.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Intel Opensource Technology Center
References: <alpine.DEB.2.00.1003101457100.28412@kaball-desktop> <alpine.DEB.2.00.1003171100310.23661@kaball-desktop> <1268850028.10129.36012.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.12.2 (Linux/2.6.31-20-generic; KDE/4.3.2; x86_64; ; )
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...

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.

Xen-devel mailing list