[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Xen-devel] [PATCH]Do some checks and settings ofCR0according to VMX capability MSRs
- To: "Keir Fraser" <keir@xxxxxxxxxxxxx>, "Liu, Eric E" <eric.e.liu@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
- From: "Li, Xin B" <xin.b.li@xxxxxxxxx>
- Date: Wed, 1 Aug 2007 15:13:09 +0800
- Delivery-date: Wed, 01 Aug 2007 00:10:59 -0700
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
- Thread-index: AcfQJJ9SFwvDkiqOSFe7z7TNqnXGEAAAhlp1APPR2gAAAzY7pQAB0oKA
- Thread-topic: [Xen-devel] [PATCH]Do some checks and settings ofCR0according to VMX capability MSRs
agree, we can evolve the code step by step.
-Xin
Working correctly with arbitrary settings of the
capabilities MSRs is clearly impossible. The real question is: what are the
most likely sorts of changes in future processors? My assumption is that
capabilities will increase and hence the constraints indicated by the
capability MSRs will decrease. In which case we can evolve the
capability-checking code over time, as Xen develops the ability to make use of
new processor features (e.g., if a future version of VMX supports paged real
mode). I don’t think it is likely that constraints will increase in future
(e.g., bits must be set or clear that could previously be set as you like; or
even that a bit that was forced one way in one version of VMX must be set the
other way in a later version). Trying to support that gracefully and well
would be a total pain, and to what end?
-- Keir
On 1/8/07
05:50, "Li, Xin B" <xin.b.li@xxxxxxxxx> wrote:
good point, and this is a two
side issue, one is hardware capability, the other is software capability,
maybe a better way is to have another CR0 value expected by software, and
use both of hardware and software expected value to get the effiective
one?
-Xin
From:
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx]
On Behalf Of Keir Fraser
Sent: Friday, July 27,
2007 4:19 PM
To: Liu, Eric E;
xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] [PATCH]Do
some checks and settings of CR0according to VMX capability
MSRs
I agree with some aspects
of this patch but not others. For example, not explicitly including
PG and PE in guest-mode cr0 value is a bad idea. If a future
processor does support e.g., paged real mode then it won’t magically
be the case that old Xen will know how to handle that. Currently we
expect and require a VMX guest always to run with
CR0.PE==1.
I’ll pull out the bits of the patch that I
like.
-- Keir
On 27/7/07 09:03, "Liu, Eric E"
<eric.e.liu@xxxxxxxxx> wrote:
According to SDM Vol 3B 19.8 Software should
consult the VMX capability MSRs to determine how bits
in CR0
are set, VMXON fails if any of these bits contains an unsupported
value. And according to
SDM Vol 3A 2.5, 3B 21.3 and 2A MOV-MOV
to/from Control Registers, setting upper 32 bits of CR0
results in a general-protection exception and setting the
reserved bits in lower 32 bits of CR0 are ignored .
In
accordance with above-mentioned, the patch is attached to do some
checks and settings of
CR0.
_______________________________________________
Xen-devel
mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
