WARNING - OLD ARCHIVES

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/
Xen

xen-devel

[Top] [All Lists]

[Xen-devel] Re: [PATCH] avoid gp fault vmexits

To: "Kamble, Nitin A" <nitin.a.kamble@xxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] avoid gp fault vmexits
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Sat, 6 May 2006 05:54:53 +0100
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Delivery-date: 2006年5月05日 21:59:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <E305A4AFB7947540BC487567B5449BA80A67CA30@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/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>
References: <E305A4AFB7947540BC487567B5449BA80A67CA30@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 6 May 2006, at 03:01, Kamble, Nitin A wrote:
Hi Keir, Ian,
    The current Xen code for VMX is setting the gp fault vmexiting in the EXCEPTION_BITMAP vmcs control. There is no need for that as VMM is just plainly re-injecting back to the guest. The attached is a simple patch to set the vmcs control properly.
 
This is a nice way round the 'int 0xff' vm86 problem. With this patch in place, might we be better to crash the guest if we see a valid IDT_VECTORING_INFO_FIELD *and* vector_injected? Unlike #GP I can't really see how a valid guest is going to end up triggering a guest-visible #PG off of an interrupt/exception delivery (and I expect #DB/#BP/#NM are all impossible). Also, the current logic will lose ExtIRQs which would be a harder problem to track down than an explicit domain_crash(). Perhaps, given that this check would get pushed inside the 'rare path' of seeing a valid IDT_VECTORING_INFO_FIELD, we could get rid of the vector_injected software flag and simply check VM_ENTRY_INTR_INFO_FIELD directly? Something like:
__vmread(IDT_VECTORING_INFO_FIELD, &idtv_info_field);
if (idtv_info_field & INTR_INFO_VALID_MASK) {
 __vmread(VM_ENTRY_INTR_INFO_FIELD, &vmentry_intr_info_field);
 if (vmentry_intr_info_field & INTR_INFO_VALID_MASK)
domain_crash_synchronous(); /* guest fault occurred during event injection */
 ....
 -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date: [Xen-devel] [PATCH] avoid gp fault vmexits , Kamble, Nitin A
Next by Date: RE: [Xen-devel] RE: [PATCH] Xenoprof passive domain support , Yang, Xiaowei
Previous by Thread: [Xen-devel] [PATCH] avoid gp fault vmexits , Kamble, Nitin A
Next by Thread: [Xen-devel] Xen porting guide , Ivan Kelly
Indexes: [Date] [Thread] [Top] [All Lists]

Copyright ©, Citrix Systems Inc. All rights reserved. Legal and Privacy
Citrix This site is hosted by Citrix

AltStyle によって変換されたページ (->オリジナル) /