WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] trap bounce flags

To: Jan Beulich <jbeulich@xxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] trap bounce flags
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Wed, 25 Apr 2007 11:10:01 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 25 Apr 2007 03:08:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <462F41F4.76E4.0078.0@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AceHIeKsIUUMtvMVEduM1gAX8io7RQ==
Thread-topic: [Xen-devel] trap bounce flags
User-agent: Microsoft-Entourage/11.3.3.061214
On 25/4/07 10:56, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> - even compat_restore_all_guest now asserts interrupts are disabled, despite
>   32-bit restore_all_guest not doing so (and the iret path not generally
>   needing this)

The 32-bit restore_all_guest ought to have the assertion added. I must have
forgotten about it. Interrupts need to be disabled during return to guest so
that the tests for softirq work and event-notification to the guest do not
race against new interrupts. Of course this issue is much less fatal than
the restore-rsp;sysret bug!

> - int80_direct_trap checks for non-zero TRAPBOUNCE_flags, yet
>   {,compat_}create_bounce_frame clear the low byte of these flags (i.e.
>   including TBF_exception, which is in this lower byte); it appears to be only
>   a lucky coincidence that this still works as the cmp (again!) is suffix-less
>   and hence gets sized as a 32-bit compare, accidentally coveringTRAPBOUNCE_cs

Ooo, good catch. It's a tiny bit gross but the best fix is probably just to
restore the flags field after the call to create_bounce_frame. And of course
change the cmp to a cmpb. Agree?

> - from the above, why is it that only the lower byte (if anything) needs
> clearing?

Really it's a one-byte field: it's consistently treated that way in asm
code. The upper byte is always zero. We should probably make the field
explicitly uint8_t. Agree?

 -- Keir


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