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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.05.12 at 15:42, "Dong, Eddie" <eddie.dong@xxxxxxxxx> wrote:
>> > 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.
> 
> Opcode 0xf1 should use " privileged software exception".
> 
> What we can do probably include:
> 1: A patch to fix the mistake of #BP & #OF, plus additional comments to state 
> the usage of the API.
> 2: Another patch to provide a new API for 0xf1 & CD nn? But we don't have 
> real usage case to test so far.
> 
> We will provide #1 quickly, but for #2, can Aravindh provide test if we get 
> the patch ready?
> 
>> 
>> >>
>> >> 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
> 
> In #UD case (fault), the guest RIP is not advanced per SDM, and therefore 
> guest will either 
> spin in the previous LOCK instruction, or advance the IP to next instruction 
> by guest #UD handler.
> I didn't see emulator could advance IP to the next instruction (INT nn) for 
> LOCK prefix.
> Do I miss something?

I'm sure you misunderstand me. I was saying that LOCK is the only
prefix we can validly assume was not present on the original
instruction.

Any other prefix could be present, and should count towards the
instruction length. Note the

        __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* int3 */

and (after the recent change for INT nn)

            __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 2); /* int imm8 */

which both use hard coded values.

Furthermore, for Aravindh's use case where there might not even
be an "original instruction" (i.e. injecting an interrupt/exception for
reasons other than emulating a respective instruction), advancing IP
seems bogus to me altogether.

>> other prefixes should consequently be considered ignored, and so
>> should the emulation do (and properly handle resulting instruction
>> lengths).
>> 
> The behavior is un-defined per SDM in this case, so either solution should be 
> fine :)

Can you please point me to where this is being stated? I particularly
doubt that for operand and address size prefixes as well as on 64-bit
- since they are documented to be ignored there - CS, DS, ES, and SS
segment prefixes...

Jan


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