This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, "Li, Xin B" <xin.b.li@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] Proper use of VMX execution controls MSR.
From: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Date: Wed, 28 Mar 2007 23:07:06 -0700
Delivery-date: Wed, 28 Mar 2007 23:06:00 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2306C24.4FFE%Keir.Fraser@xxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcdxUQOcmZ2ehsIdTvOT1iiVu1vOEgAEiiMSABfrpzA=
Thread-topic: [Xen-devel] [PATCH] Proper use of VMX execution controls MSR.
Keir Fraser wrote:
> 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!). 

Right. BUG_ON() is correct because the processor does not meet the
programmer's assumption. 

> 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.

This is okay because newer processors simply provide more settings, i.e
1 => 0 or 1. The code usually is written with the setting = 1. Some VMM
may use the setting 0 for new processors if it can benefit from that.

>  -- Keir

Intel Open Source Technology Center

Xen-devel mailing list