Signed-off-by: Boris Ostrovsky boris.ostrovsky@oracle.com Cc: stable@vger.kernel.org --- arch/x86/xen/xen-pvh.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S index 934f7d4..373fef0 100644 --- a/arch/x86/xen/xen-pvh.S +++ b/arch/x86/xen/xen-pvh.S @@ -93,7 +93,7 @@ ENTRY(pvh_start_xen) mov %eax, %cr0
/* Jump to 64-bit mode. */ - ljmp $__KERNEL_CS, $_pa(1f) + ljmp $__BOOT_CS, $_pa(1f)
/* 64-bit entry point. */ .code64
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."
Jan
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).
-boris
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.
Jan
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.
-boris
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
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
linux-stable-mirror@lists.linaro.org
-
Andrew Cooper -
Boris Ostrovsky -
Jan Beulich