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