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: Sheng Yang <sheng@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH][v9 4/6] xen/hvm: Xen PV extension of HVM initialization
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Mon, 15 Mar 2010 12:04:16 +0000
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Yaozu \(Eddie\) Dong" <eddie.dong@xxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, Fraser <Keir.Fraser@xxxxxxxxxxxxx>, Keir
Delivery-date: Mon, 15 Mar 2010 05:00:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <201003150945.09548.sheng@xxxxxxxxxxxxxxx>
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>
References: <1268362647-5317-1-git-send-email-sheng@xxxxxxxxxxxxxxx> <1268362647-5317-5-git-send-email-sheng@xxxxxxxxxxxxxxx> <4B9AA5A9.20609@xxxxxxxx> <201003150945.09548.sheng@xxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Mon, 15 Mar 2010, Sheng Yang wrote:
> > > +#ifdef CONFIG_XEN_HVM_PV
> > > +
> > > +#define XEN_HVM_PV_CLOCK_ENABLED   (1u<<  0)
> > 
> > Why is this flag needed?  As far as I understand it, there's no real
> > underlying hypervisor change needed to make HVM access to pv clock
> > possible; its just a field in the shared_info's vcpu struct after all.
> > Even if you enable this feature unconditionally, the user can still
> > control whether the Xen clocksource is used with the "clocksource="
> > kernel command-line parameter.
> 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

> > Also, there's nothing about this which is 64-bit specific is there?
> 64 bit things are mostly evtchn/interrupt related. I think no such limit 
> here. 
> But I think it's better to do it step by step, so leave it after evtchn 
> solution settled.

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...).

Xen-devel mailing list