Re: [Xen-devel] Intel: GPF from lret to load CS with weird error code

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 31.05.13 at 02:16, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> On Thu, 30 May 2013 07:03:24 +0100
> "Jan Beulich" <jbeulich@xxxxxxxx> wrote:
> 
>> >>> Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> 05/30/13 4:02 AM >>>
>> >Guest (PVH) is running in vmx in 64bit mode,  it loads CS:
>> >
>> >ffffffff810034d2: 2:load_cs+12                   push
>> >$0x10 ffffffff810034d4: 2:load_cs+14                   lea
>> >0x2(%rip), %rax ffffffff810034db: 2:load_cs+1b
>> >push %rax ffffffff810034dc: 2:load_cs+1c
>> >lret                    
>> >
>> >The lret causes a GP. But the error code is strange (0xfffc):
>> 
>> This is a strong hint at the lret lacking a REX64 override, and hence
>> the high 32 bits of the intended RIP being taken as target CS. lret,
>> other than ret, doesn't default to 64 bit operand size.
> 
> Grrrrr.... rats! Thats all that was and I spent so much time on it! I'd
> have thought along those lines if the err code was (0xffff) which is what
> it should be if it's loading high 32bits as CS, so is still a hardware
> bug IMO, or may be the 'ret' man page should say, #GP(0), #GP(selector),
> or #GP(somewhere in between).

That's absolutely documented behavior - what are the RPL bits in
the selector registers have a different meaning in error codes.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel