[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] RE: [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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.