[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest
On Wed, May 2, 2012 at 5:25 PM, Dong, Eddie <eddie.dong@xxxxxxxxx> wrote: >> >> >> >> Jun, Eddie - I further wonder why #OF is not being handled according >> >> to the documentation here either (should also result in >> >> X86_EVENTTYPE_SW_EXCEPTION). And the fall-through from >> >> TRAP_debug to TRAP_int3 is suspicious too (at the very minimum it >> >> should be annotated with a comment saying why fall-through is >> >> intended here). Nor does the documentation state that TRAP_debug >> >> should ever result in X86_EVENTTYPE_SW_EXCEPTION. >> > >> > Mmm, SDM requires us to use X86_EVENTTYPE_SW_EXCEPTION for #OF & >> #BP, >> > It seems we are slightly different here. Let me check w/ internal person. >> >> Thanks. > > The TRAP_debug should not use SW_EXCEPTION, it should use HW_EXCEPTION > Per SDM and confirmation from our HW guys. We will send fixes soon. > > >> >> >> Finally, the whole injection logic (including the patch here) doesn't >> >> appear to cope with INT nn being used by a guest with nn < 32, nor >> > >> > The original code path works for the privilege violation introduced >> > exceptions, >> > It seems we probbaly need a new code for INT n emulation for both >> interrupt & >> > exceptions. >> >> Indeed. > > This API vmx_inject_hw_exception is never intended to be used for INT nn > emulation, > Rather it is designed for the exceptions generated by processor-detected > program-error exceptions and machine check exceptions. > > If the purpose of Aravindh's patch is for INT nn emulation (CD nn), it is > incorrect. We need a new API for that purpose, and use software interrupt. > Of course, for INTO & INT 3 (CE & CC), we should use SW_EXCEPTION as SDM > mentioned. > The reason I submitted the patch was, calling xc_hvm_inject_trap() on a software interrupt caused the guest to crash with a vmentry failure because the interrupt was injected as a hardware interrupt. The patch allowed me to inject a software interrupt successfully. However I do agree that it is better if we have a separate API that does not overload vmx_inject_hw_exception(). Thanks, Aravindh _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |