|
[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 03.05.12 at 02:25, "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. Please also have the opcode 0xF1 generated #DB addressed in whatever is the appropriate way. >> >> 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. I'm sure he took it to be the correct one because it previously handled #BP too. >> >> with any (pointless) prefixes used on INT3 or INT nn. >> >> >> > What specific prefix do u mean here? >> >> Anyone except perhaps LOCK - none of them should have any effect >> other than making the instruction longer. >> > LOCK can never be used as prefix of INT nn instruction, nor can REPx prefix. > Can you provide more details as for this concern? The only prefix that is documented to cause #UD here is LOCK. All other prefixes should consequently be considered ignored, and so should the emulation do (and properly handle resulting instruction lengths). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |