[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


Xen-devel mailing list



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