From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: trap bounce flags Date: Wed, 25 Apr 2007 11:33:03 +0100 Message-ID: <462F4A7F.76E4.0078.0@novell.com> References: <462F41F4.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com, Ian Campbell List-Id: xen-devel@lists.xenproject.org >> - 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 coveringTRAPBOU= NCE_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? 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. >> - 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 Jan