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] vmx & efer

To: "Jan Beulich" <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] vmx & efer
From: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Date: Fri, 4 May 2007 09:44:17 -0700
Delivery-date: Fri, 04 May 2007 09:42:50 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <463B7064.76E4.0078.0@xxxxxxxxxx>
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: AceOYsK4qpb5yQbxS1iowqqxkbGU6QAAatCQ
Thread-topic: [Xen-devel] vmx & efer
Jan Beulich wrote:
> Am I blind in that I cannot find the place where the guest intended
> EFER value gets loaded into the CPU register? The VMCS has no field
> for this (other than AMD's VMCB), and the guest_msr_state->flags bit
> for this register doesn't get set anywhere. I'm implying that the
> guest thus always runs with all features enabled that were enabled by
> the hypervisor (slight security issue, as EFER.SCE set implies LSTAR
> was initialized, which may not be true). 

The bit LMA and LME are automaticaly are loaded by the hardware. Please
look at the spec (Volume 3B). For SCE, we discussed a while ago, but can
you please elaborate on the security issues?

> Further I am quite confused about the saving and restoring of CSTAR -
> all parts of the SDM state or imply that this register doesn't exist
> (as syscall is supposedly invalid in compatibility mode), so it
> wouldn't need saving/restoring at all; there's one exception though:
> section says "SYSCALL/SYSRET invocations can occur from
> either 32-bit compatibility mode application code or from 64-bit
> application code." 

I agree that it's slightly confusing, but the previous sentence says
"They are available only in 64-bit mode and only when the SCE bit of the
IA32_EFER MSR is set." 

The reason we save/restore CSTAR is that x86-64 Linux (still) writes to
it  because it did exist before. But I think we can stop doing that.

> Thanks, Jan
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Intel Open Source Technology Center

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>