[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cb819dcb-1597-680e-31b3-b63fecb6d4c1@oracle.com>
Date: Wed, 2 May 2018 11:08:53 -0400
From: Boris Ostrovsky <boris.ostrovsky@...cle.com>
To: Jan Beulich <JBeulich@...e.com>
Cc: xen-devel <xen-devel@...ts.xenproject.org>,
Juergen Gross <jgross@...e.com>, linux-kernel@...r.kernel.org,
stable@...r.kernel.org
Subject: Re: [Xen-devel] [PATCH 2/4] xen/PVH: Use proper CS selector in long
mode
On 05/02/2018 11:00 AM, Jan Beulich wrote:
>>>> On 02.05.18 at 16:57, <boris.ostrovsky@...cle.com> wrote:
>> On 05/02/2018 04:05 AM, Jan Beulich wrote:
>>>>>> On 30.04.18 at 18:23, <boris.ostrovsky@...cle.com> wrote:
>>>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@...cle.com>
>>> Reviewed-by: Jan Beulich <jbeulich@...e.com>
>>>
>>> But to understand why things have been working nevertheless it would
>>> have been nice if the commit message wasn't empty, but instead said
>>> something like "The two happen to be identical on 64-bit."
>>
>> Why do you think they are identical? __KERNEL_CS points to entry#12
>> (which we don't specify in PVH GDT) while __BOOT_CS is the second entry
>> (which we do create).
> That's 32-bit's __KERNEL_CS. If the two weren't identical, the ljmp
> you adjust would never have worked afaict.
Oh, right. My theory was that we were picking up something from the
stack (which is where 12th entry would be pointing) and the L bit, which
I think is the only one we'd care about, happened to always be set there.
-boris
Powered by blists - more mailing lists