[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 20.04.12 at 07:04, Aravindh Puthiyaparambil <aravindh@xxxxxxxxxxxx> 
>>> wrote:
> If xc_hvm_inject_trap() is called on a software (user defined) interrupt, it 
> causes the guest to crash with a vmentry failure. The following patch fixes 
> this issue.
> 
> Signed-off-by: Aravindh Puthiyaparambil <aravindh@xxxxxxxxxxxx>
> 
> diff -r 9036d6f974de -r f60377584f2d xen/arch/x86/hvm/vmx/vmx.c
> --- a/xen/arch/x86/hvm/vmx/vmx.c      Thu Apr 19 21:55:51 2012 -0700
> +++ b/xen/arch/x86/hvm/vmx/vmx.c      Thu Apr 19 22:01:50 2012 -0700
> @@ -1374,6 +1374,13 @@ void vmx_inject_hw_exception(int trap, i
>  
>          type = X86_EVENTTYPE_SW_EXCEPTION;
>          __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* int3 */
> +        break;
> +    default:
> +        if ( trap > TRAP_last_reserved )
> +        {
> +            type = X86_EVENTTYPE_SW_EXCEPTION;
> +            __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 2); /* int imm8 */

I doubt this is generally correct, in particular for the use you appear
to desire: When the injection is not the result of an INT nn
instruction (which I would guess to be the case when coming from
libxc), you shouldn't set a non-zero instruction length. I believe this
is also wrong for the INT3 code above.

Additionally the problem should not be limited to injection coming
from libxc - injection originating from x86_emulate() should be
affected as much.

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.

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
with any (pointless) prefixes used on INT3 or INT nn.

Jan

> +        }
>      }
>  
>      if ( unlikely(intr_info & INTR_INFO_VALID_MASK) &&
> diff -r 9036d6f974de -r f60377584f2d xen/include/asm-x86/processor.h
> --- a/xen/include/asm-x86/processor.h Thu Apr 19 21:55:51 2012 -0700
> +++ b/xen/include/asm-x86/processor.h Thu Apr 19 22:01:50 2012 -0700
> @@ -111,6 +111,7 @@
>  #define TRAP_alignment_check  17
>  #define TRAP_machine_check    18
>  #define TRAP_simd_error       19
> +#define TRAP_last_reserved    31
>  
>  /* Set for entry via SYSCALL. Informs return code to use SYSRETQ not IRETQ. 
> */
>  /* NB. Same as VGCF_in_syscall. No bits in common with any other TRAP_ 
> defn. */
> 
> _______________________________________________
> 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


 


Rackspace

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