Re: [Xen-devel] trap bounce flags

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>> - 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?

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


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