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

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