On 02/05/18 16:09, Jan Beulich wrote:
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).
The type/s/dpl/p/d/l attributes still very much matter even in 64bit.
~Andrew