Re: [Xen-devel] [PATCH 1/2] x86/pv: Fix bugs with the handling of int80_bounce

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.05.17 at 12:04, <andrew.cooper3@xxxxxxxxxx> wrote:
> Testing has revealed two issues:
> 
>  1) Passing a NULL handle to set_trap_table() is intended to flush the entire
>     table.  The 64bit guest case (and 32bit guest on 32bit Xen, when it
>     existed) called init_int80_direct_trap() to reset int80_bounce, but c/s
>     cda335c279 which introduced the 32bit guest on 64bit Xen support omitted
>     this step.  Previously therefore, it was impossible for a 32bit guest to
>     reset its registered int80_bounce details.
> 
>  2) init_int80_direct_trap() doesn't honour the guests request to have
>     interrupts disabled on entry.  PVops Linux requests that interrupts are
>     disabled, but Xen currently leaves them enabled when following the int80
>     fastpath.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
with a remark:

> --- a/xen/arch/x86/x86_64/traps.c
> +++ b/xen/arch/x86/x86_64/traps.c
> @@ -427,12 +427,13 @@ void init_int80_direct_trap(struct vcpu *v)
>      struct trap_info *ti = &v->arch.pv_vcpu.trap_ctxt[0x80];
>      struct trap_bounce *tb = &v->arch.pv_vcpu.int80_bounce;
>  
> -    tb->flags = TBF_EXCEPTION;
>      tb->cs    = ti->cs;
>      tb->eip   = ti->address;
>  
>      if ( null_trap_bounce(v, tb) )
>          tb->flags = 0;
> +    else
> +        tb->flags = TBF_EXCEPTION | (TI_GET_IF(ti) ? TBF_INTERRUPT : 0);
>  }

This certainly is a correct change to make, but it's not without risk:
If some guest relies on previous buggy behavior (wrongly setting
the flag but expecting interrupts to be on), ugly misbehavior in the
guest could result. Initially I was afraid XenoLinux might be
affected, but I've checked and it isn't.

Jan


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