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


[Xen-devel] vmx & efer

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] vmx & efer
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Fri, 04 May 2007 16:41:56 +0100
Delivery-date: Fri, 04 May 2007 08:40:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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
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).

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

Thanks, Jan

Xen-devel mailing list

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