Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-Id: <5AE9D49B02000078001C0322@prv1-mh.provo.novell.com>
Date:   Wed, 02 May 2018 09:09:15 -0600
From:   "Jan Beulich" <JBeulich@suse.com>
To:     "Boris Ostrovsky" <boris.ostrovsky@oracle.com>
Cc:     "xen-devel" <xen-devel@lists.xenproject.org>,
        "Juergen Gross" <jgross@suse.com>, <linux-kernel@vger.kernel.org>,
        <stable@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/4] xen/PVH: Use proper CS selector in
 long mode
References: <20180430162339.17143-1-boris.ostrovsky@oracle.com>
 <20180430162339.17143-3-boris.ostrovsky@oracle.com>
 <5AE9713D02000078001C007B@prv1-mh.provo.novell.com>
 <6b7a748d-e289-c370-123a-678c6ad7d9dd@oracle.com>
 <5AE9D27402000078001C02ED@prv1-mh.provo.novell.com>
 <cb819dcb-1597-680e-31b3-b63fecb6d4c1@oracle.com>
In-Reply-To: <cb819dcb-1597-680e-31b3-b63fecb6d4c1@oracle.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

>>> On 02.05.18 at 17:08, <boris.ostrovsky@oracle.com> wrote:
> On 05/02/2018 11:00 AM, Jan Beulich wrote:
>>>>> On 02.05.18 at 16:57, <boris.ostrovsky@oracle.com> wrote:
>>> On 05/02/2018 04:05 AM, Jan Beulich wrote:
>>>>>>> On 30.04.18 at 18:23, <boris.ostrovsky@oracle.com> wrote:
>>>>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>>> Reviewed-by: Jan Beulich <jbeulich@suse.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.

I don't think the L bit is the only one we care about, as I don't think you
can load a non-code selector into CS (even if none of the attributes are
later used for anything).

Jan