[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.