[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


 


Rackspace

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