monitor_table is getting set to 0 for domu x86_64

monitor_table is pfn 0 when __context_switch goes to set cr3 for a second domain.

I hacked update_pagetables to print out what monitor_table gets set to, here's the output while launching a domu:

(XEN) guest_table_user: 0x0
(XEN) shadow_table: 0x0
(XEN) guest_table: 0x169b
(XEN) using guest_table_user: 0x0
..
(XEN) cs: monitor_table: 0x0
(XEN) Domain 1 (vcpu#0) crashed on cpu#0:
..

While the attached patch takes care of the problem, and i don't understand everything i know about TF_kernel_mode and guest_table_user, so likely a better solution is in order. If somebody wouldn't mind saying a few words about either of these, i'd appreciate it.

With this patch i can tell that a domU actually makes some progress (judging from the register state), before falling on its face when it makes its first syscall.

Huge props to Jerone for pointing out sync_console to me!

sRp

Scott Parish
Signed-off-by: [email protected]

@@ -1700,7 +1700,8 @@ static inline void update_pagetables(str
     if ( likely(!shadow_mode_external(d)) )
     {
 #ifdef __x86_64__
-        if ( !(v->arch.flags & TF_kernel_mode) )
+        if ( !(v->arch.flags & TF_kernel_mode) &&
+             pagetable_get_pfn(v->arch.guest_table_user) )
             v->arch.monitor_table = v->arch.guest_table_user;
         else
 #endif

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

I retract said patch--after understanding more of what i knew about TF_kernel_mode, and looking into the syscall problem, it seems clear that the problem is that TF_kernel_mode isn't set.

So now the question is, why is TF_kernel_mode is getting cleared by arch_set_info_guest()? (or why isn't VGCF_IN_KERNEL set?)

sRp

Scott Parish
Signed-off-by: [email protected]