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

[Keir Fraser <keir.xen@xxxxxxxxx>]

On 03/05/2012 14: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.

Yes, this sounds great.

 -- Keir

> 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?
> 
>> 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 :)
> 
> Thx, Eddie
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel



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