[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: "Li, Xin B" <xin.b.li@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Wed, 28 Mar 2007 19:01:56 +0100
  • Delivery-date: Wed, 28 Mar 2007 10:59:53 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdxUQOcmZ2ehsIdTvOT1iiVu1vOEgAEiiMS
  • Thread-topic: [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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.