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