On 07/17/2015 11:21 AM, Konrad Rzeszutek Wilk wrote:
On Thu, Jul 16, 2015 at 05:43:39PM -0400, Boris Ostrovsky wrote:
Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com>
---
Changes in v2:
* Set segment selectors using loadsegment() instead of assembly
arch/x86/xen/enlighten.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index f8dc398..d665b1d 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1362,12 +1362,12 @@ static void __init xen_boot_params_init_edd(void)
static void __ref xen_setup_gdt(int cpu)
{
if (xen_feature(XENFEAT_auto_translated_physmap)) {
-#ifdef CONFIG_X86_64
- unsigned long dummy;
+ unsigned long __attribute__((unused)) dummy;
- load_percpu_segment(cpu); /* We need to access per-cpu area */
You removed that - where are we going to do that? As the
'switch_to_new_gdt' uses the per-cpu GDT table.
load_percpu_segment() is part of switch_to_new_gdt(), so I thought there
is no need to call it here.
But you are right --- switch_to_new_gdt() starts with
get_cpu_gdt_table() which accesses per-CPU area. How did this manage to
work then?
+ setup_stack_canary_segment(cpu);
As this one too ?
This one I added. On 64-bit it's a nop so we never had problems without
having this call. On 32-bit, if CC_STACKPROTECTOR is set, we will fail
without setting this up.
-boris
switch_to_new_gdt(cpu); /* GDT and GS set */
+#ifdef CONFIG_X86_64
/* We are switching of the Xen provided GDT to our HVM mode
* GDT. The new GDT has __KERNEL_CS with CS.L = 1
* and we are jumping to reload it.
@@ -1392,8 +1392,13 @@ static void __ref xen_setup_gdt(int cpu)
loadsegment(ds, 0);
loadsegment(fs, 0);
#else
- /* PVH: TODO Implement. */
- BUG();
+ asm volatile ("ljmp %0,$1f\n"
+ "1:\n"
+ :: "i" (__KERNEL_CS));
+
+ loadsegment(ss, __KERNEL_DS);
+ loadsegment(ds, __USER_DS);
+ loadsegment(es, __USER_DS);
#endif
return; /* PVH does not need any PV GDT ops. */
}
--
1.8.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
