Re: trap bounce flags

[Keir Fraser <keir@xensource.com>]

On 25/4/07 10:56, "Jan Beulich" <jbeulich@novell.com> 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