[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |