| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx> |
|
Date: |
Tue, 16 Mar 2010 10:12:10 -0700 |
|
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: |
Tue, 16 Mar 2010 10:17:14 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<201003160951.48973.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> <alpine.DEB.2.00.1003151108151.27222@kaball-desktop> <4B9EBBEE.9020107@xxxxxxxx> <201003160951.48973.sheng@xxxxxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.3 |
On 03/15/2010 06:51 PM, Sheng Yang wrote:
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?
I think that's a bit arbitrary. If we need a new vcpuop to make it work
properly anyway (set tsc offset), then the presence of that should be a
good indicator. In other words, make it depend on its actual fixed
pre-reqs, rather than a specific flag for the feature.
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.
What kinds of issues?
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home