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 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: [Xen-devel] RE: [PATCH] avoid gp fault vmexits
From: "Kamble, Nitin A" <nitin.a.kamble@xxxxxxxxx>
Date: Tue, 9 May 2006 11:54:16 -0700
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Delivery-date: Tue, 09 May 2006 11:55:11 -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
Thread-index: AcZwyczWu/74JCE2TteJ4gT8CMZIKwCzxGzQ
Thread-topic: [PATCH] avoid gp fault vmexits
Hi Keir,

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

enable_irq_window() is helping not loose the ExtIRQ. We have not seen
the ExtIRQ being lost. But still there is a very rare possibility of
loosing it. And I think we should add printks to expose such lost
ExtIRQs.

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


This still needs the extra vmread for IDT_VECTORING_INFO_FIELD for every
vmexit time.

Thanks & Regards,
Nitin
------------------------------------------------------------------------
----
Open Source Technology Center, Intel Corp

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

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