| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
> > XEN_HVM_PV_CLOCK_ENABLED.
>
> 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.
--
regards
Yang, Sheng
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home