[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Xen-devel] [PATCH]Do some checks and settings of CR0according 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 12:50:37 +0800
- Delivery-date: Tue, 31 Jul 2007 21:48:16 -0700
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
- Thread-index: AcfQJJ9SFwvDkiqOSFe7z7TNqnXGEAAAhlp1APPR2gA=
- Thread-topic: [Xen-devel] [PATCH]Do some checks and settings of CR0according to VMX capability MSRs
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
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
|
