[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] trap bounce flags


  • To: Jan Beulich <jbeulich@xxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Wed, 25 Apr 2007 12:26:08 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 25 Apr 2007 04:24:56 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AceHLITRw3zGcvMfEduM1gAX8io7RQ==
  • Thread-topic: [Xen-devel] trap bounce flags

On 25/4/07 12:11, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> Which means there's not really a dependency on this being non-zero...

Yeah, I limited that dependency just to the handle_exception path. It now
zeroes the flags field itself which. It might be even cleaner to host the
zero of the flags field to before the indirect call to the
exception-specific C handler (that's the only thing that might set up the
bounce structure).

> The patch looks otherwise okay to me, though I think there's one more
> issue here: There's another suffix-less instruction (updating UREGS_rip
> in int80_slow_path) - this must be a subq, and it must imply that no 32-bit
> guest places an int $0x80 at 0xfffffffe.

Yep.

> And my patch has a not directly related adjustment removing the
> 
>         movl  $TRAP_syscall,UREGS_entry_vector+8(%rsp)
> 
> close to the end of compat_create_bounce_frame, as this is meaningless
> here.

Should we also remove it from compat_hypercall?

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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