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][v9 4/6] xen/hvm: Xen PV extension of HVM initial

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] [PATCH][v9 4/6] xen/hvm: Xen PV extension of HVM initialization
From: Sheng Yang <sheng@xxxxxxxxxxxxxxx>
Date: Tue, 16 Mar 2010 09:51:48 +0800
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, "Yaozu \(Eddie\) Dong" <eddie.dong@xxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Mon, 15 Mar 2010 18:52:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B9EBBEE.9020107@xxxxxxxx>
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: <1268362647-5317-1-git-send-email-sheng@xxxxxxxxxxxxxxx> <alpine.DEB.2.00.1003151108151.27222@kaball-desktop> <4B9EBBEE.9020107@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.12.2 (Linux/2.6.31-20-generic; KDE/4.3.2; x86_64; ; )
On Tuesday 16 March 2010 06:59:58 Jeremy Fitzhardinge wrote:
> On 03/15/2010 05:04 AM, Stefano Stabellini wrote:
> >> 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
> The only reason why we wouldn't want to do this is if we want to
> withdraw this feature at some point in the future.  We're stuck with it
> indefinitely for PV, but I don't know if that's necessarily going to be
> the case for HVM.  On the other hand, if other - better - mechanisms
> become available, we can give them their own clocksource driver with a
> higher priority than the Xen pvclock one, and users can still select
> clocksources on the kernel command line.

So you think about adding a new XENFEAT?
> > 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...).
> Seems like making it work for both 32 and 64-bit is the easiest thing to
>  do.

If it is, it should be fine. But I had encountered some issues on 32 bits.

Yang, Sheng

Xen-devel mailing list