[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

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.