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]: Add handlers for missing exit_reasons documente

To: "Liu, Yuan B" <yuan.b.liu@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH]: Add handlers for missing exit_reasons documented by Intel SDM 3B
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Fri, 3 Sep 2010 09:39:43 +0100
Cc: "Dong, Eddie" <eddie.dong@xxxxxxxxx>, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Delivery-date: Fri, 03 Sep 2010 01:41:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <BC00F5384FCFC9499AF06F92E8B78A9E1837FFC1C6@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: ActLLt68YhdYhTmESzyAYnKD3a12ywACNKOqAAG9kUAAATmm1A==
Thread-topic: [Xen-devel] [PATCH]: Add handlers for missing exit_reasons documented by Intel SDM 3B
User-agent: Microsoft-Entourage/
On 03/09/2010 09:29, "Liu, Yuan B" <yuan.b.liu@xxxxxxxxx> wrote:

> According to the SDM, GETSEC, INVEPT, INVVPID can be executed by guests in
> some cases. For e.g.
> GETSEC(SDM 2B 6.2.1)
> System software enables SMX operation by setting CR4.SMXE[Bit 14] = 1 before
> attempting to execute GETSEC. Otherwise, execution of GETSEC results in the
> processor signaling an invalid opcode exception (#UD).
> Since Xen doesn't permit guests to set the SMXE bit in CR4 (refer to
> hvm_set_cr4 in hvm.c) GETSEC should generate an #UD instead of referring to
> default handler.

Well actually given that CR4.SMXE always is 0 when the guest runs, the
VMEXIT will never be taken, since the CPU checks CR4.SMXE before checking
for running in non-root context.

I guess I agree with the patch overall. I would consider putting a
WARN_ON(1) on the GETSEC vmexit path, with a code comment explaining it
should be unreachable currently. What do you think? I can make that change
myself if you agree.

 -- Keir

Xen-devel mailing list