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] 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

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

>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,
Open Source Technology Center, Intel Corp

Xen-devel mailing list

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