RE: [Xen-devel] [PATCH] x86 emulation: fix bswap

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Keir Fraser
> Sent: 15 February 2007 10:33
> To: Jan Beulich; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH] x86 emulation: fix bswap
> 
> On 15/2/07 10:22, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
> 
> > REX.R needs to be decoded and since bswap on a 16-bit 
> operand is undefined,
> > it is best to have hardware execute this so the emulation 
> result matches
> > hardware behavior. Since it is simple to do, faster, and 
> smaller, also let
> > hardware do 32- and 64-bit ones.
> 
> Can 'undefined' behaviour include e.g. #UD?

BSWAP isn't allowed to #UD ("Exceptions: None") according to Vol 3 of
AMD64 Programmers Manual. A 16-bit prefix to that instruction is just
not defined - it will do SOMETHING, but it won't crash the system, just
"randomly store data in your target register" [I haven't tried it, and
it may well vary depending on model of processor as well as of course
differences between different companies processors]. I would expect the
usage of 66 0F C8 <reg> to be extremely unusual - there is the "correct"
way to do it with XCHG AL,AH and related instructions. 

If anything is going to trap, it will be on the next instruction, when
the data is garbled. 

I just wrote a little bit of code to test it: 
int x = 0x12345678;
__asm__(".byte 0x66; bswap %0": "=r"(x): "0"(x))
printf("x=%x", x); 

Prints 12340000, so the data is "zerod". (and it looks like the code
generated by gcc is correct!). 


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



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