RE: [Xen-devel] [PATCH] Proper use of VMX execution controls MSR.

["Cui, Dexuan" <dexuan.cui@xxxxxxxxx>]

The patch conforms to the spec strictly, but I also think the spec is really 
odd...
Seems Keir hasn't checked it in.

 -- Dexuan

>-----Original Message-----
>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keir Fraser
>Sent: 2007年3月29日 2:02
>To: Li, Xin B; xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: Re: [Xen-devel] [PATCH] Proper use of VMX execution controls MSR.
>
>On 28/3/07 16:51, "Li, Xin B" <xin.b.li@xxxxxxxxx> wrote:
>
>> Better use of VMX execution controls MSR.
>>
>> Signed-off-by: Xin Li<xin.b.li@xxxxxxxxx>
>
>Is this actually to fix a problem with a future processor?
>
>This whole bit-forcing thing seems extremely odd to me. We set the controls
>that Xen currently needs to do its job as a VMM properly -- we can't just
>clear some of those controls because the processor says to do so. So I think
>our current treatment of the MSR high bits is appropriate (if it tells us to
>zero one of the control bits that we make use of, we are in trouble -- we
>have a processor that isn't backwards compatible!).
>
>I also feel uneasy about setting extra bits (as specified by the MSR low
>bits), but I reason that if we are told to set bits of flags which are
>currently architecturally-undefined then it is reasonable to let the
>processor tell us what to do with them. Which is why I do respect the MSR
>low bits.
>
>Why did Intel ever choose this insane scheme? Would it have been so hard to
>have defined bitmaps with set-to-enable semantics, and always require zero
>for reserved bits? Actually I suppose you do have set-to-enable semantics
>(otherwise my current asymmetric treatment of MSR high and low words would
>not make sense). But all this messing with setting vs. clearing reserved
>bits seems pretty stupid.
>
> -- Keir
>
>
>
>_______________________________________________
>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