Re: [Xen-devel] [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

> >>
> >> 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.

> 
> >> 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?

Thx, Eddie


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel