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>
Subject: Re: [Xen-devel] trap bounce flags
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Wed, 25 Apr 2007 11:41:49 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Delivery-date: Wed, 25 Apr 2007 03:40:41 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <462F4A7F.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: AceHJlPukmWRSPMZEduM1gAX8io7RQ==
Thread-topic: [Xen-devel] trap bounce flags
User-agent: Microsoft-Entourage/11.3.3.061214
On 25/4/07 11:33, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> That's the alternative solution I considered. The preferable one is to do the
> compat/native distinction before the null check, and then be consistent with
> the rest of the code and check cs for 32-bit guest and eip for 64-bit ones.
> That's how I'm preparing a patch right now.

Attached is my own proposed patch which I think cleans up all the issues.
Checking just flags in asm and keeping the null-bounce check in
init_int80_direct_trap() seems fine to me.

 -- Keir

>>> - 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?
> 
> Making it a uint8_t is fine. It is, however, far from being consistently
> handled
> in assembly code:
> x86_32/entry.S: 4 word refs and 3 byte refs
> x86_64/entry.S: 6 word refs, 3 byte refs, and one size-less ref
> x86_64/compat/entry.S: 4 word refs and 3 byte refs

Attachment: 00-fix-trapbounce
Description: Binary data

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