Hi Keir, Ian,
The current Xen code for VMX is setting the gp fault vmexiting in
the EXCEPTION_BITMAP vmcs control. There is no need for that as VMM is
just plainly re-injecting back to the guest. The attached is a simple
patch to set the vmcs control properly.
Signed-Off-By: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-Off-By: Jun Nakajima <jun.nakajima@intel.com>
Thanks & Regards,
Nitin
------------------------------------------------------------------------
-----------
Open Source Technology Center, Intel Corp
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On 6 May 2006, at 03:01, Kamble, Nitin A wrote:> Hi Keir, Ian, > The current Xen code for VMX is setting the gp fault vmexiting in > the EXCEPTION_BITMAP vmcs control. There is no need for that as VMM is > just plainly re-injecting back to the guest. The attached is a simple > patch to set the vmcs control properly. >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(). 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 */ .... -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@lists.xensource.com http://lists.xensource.com/xen-devel
On 9 May 2006, at 19:54, Kamble, Nitin A wrote:> > This still needs the extra vmread for IDT_VECTORING_INFO_FIELD for > every > vmexit time.Having thought about it some more I''m quite happy with the current code. It will mean that we continue to work even if we choose to vmexit on #GP (which we still do on debug builds). If you can come up with cheap code to detect lost ExtIRQs that''d be nice but it''s really not very critical at all. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel