nestedsvm: fix paging mode

PATCH In review Christoph Egger 2 participants 7 messages Sep 21, 2012 – Oct 5, 2012

Share & tools

Christoph Egger

author

2012-09-21 14:01 UTC #0 lore raw

PATCH 1/1 nestedsvm: fix paging mode

On VMRUN and VMEXIT emulation update the paging mode for Shadow-on-Nested. This allows Xen to walk the l1 hypervisors shadow page table correctly. Problem found with 64bit Win7 and 32bit XPMode where Win7 switches forth and back between long mode and PAE legacy pagetables.

Signed-off-by Christoph Egger <[email protected]>

P.S.: Please apply this patch to xen-4.2-testing as well.

Signature · 6 lines

---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

xen/arch/x86/hvm/svm/nestedsvm.c +10 -0

diff -r ef514a30fd70 xen/arch/x86/hvm/svm/nestedsvm.c
@@ -745,6 +745,11 @@ nsvm_vcpu_vmrun(struct vcpu *v, struct c
         return 1;
     }
 
+    /* If we use nested paging and l1 guest uses shadow paging ... */
+    if (paging_mode_hap(v->domain) && !nestedhvm_paging_mode_hap(v))
+        /* ... update the paging modes. */
+        paging_update_paging_modes(v);
+
     nv->nv_vmswitch_in_progress = 0;
     return 0;
 }

@@ -1412,6 +1417,11 @@ nestedsvm_vcpu_vmexit(struct vcpu *v, st
      */
     rc = nhvm_vcpu_vmexit(v, regs, exitcode);
 
+    /* If we use nested paging and l1 guest uses shadow paging ... */
+    if (paging_mode_hap(v->domain) && !nestedhvm_paging_mode_hap(v))
+        /* ... update the paging modes. */
+        paging_update_paging_modes(v);
+
     nv->nv_vmswitch_in_progress = 0;
 
     if (rc)

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

Tim Deegan

2012-09-27 14:53 UTC #1 lore raw

Quoted 9 lines · Christoph Egger

On VMRUN and VMEXIT emulation update the paging mode for Shadow-on-Nested. This allows Xen to walk the l1 hypervisors shadow page table correctly. Problem found with 64bit Win7 and 32bit XPMode where Win7 switches forth and back between long mode and PAE legacy pagetables.
Signed-off-by Christoph Egger <[email protected]>

Don't you have to do this in other cases as well? I think that shadow-on-shadow might need it, at least.

Tim.

Christoph Egger

author

2012-10-01 13:50 UTC #2 lore raw

Quoted 9 lines · Tim Deegan

Quoted 8 lines · Christoph Egger
On VMRUN and VMEXIT emulation update the paging mode for Shadow-on-Nested. This allows Xen to walk the l1 hypervisors shadow page table correctly. Problem found with 64bit Win7 and 32bit XPMode where Win7 switches forth and back between long mode and PAE legacy pagetables.

Quoted 4 lines

Quoted 1 line
Signed-off-by Christoph Egger <[email protected]>
Don't you have to do this in other cases as well? I think that shadow-on-shadow might need it, at least.

It is needed for all cases where the l1 guest does shadow paging. This includes: Shadow-on-Nested and Shadow-on-Shadow.

Christoph

Signature · 6 lines

---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

Tim Deegan

2012-10-04 10:37 UTC #3 lore raw

Quoted 11 lines · Christoph Egger

Quoted 9 lines · Tim Deegan
Quoted 8 lines · Christoph Egger
On VMRUN and VMEXIT emulation update the paging mode for Shadow-on-Nested. This allows Xen to walk the l1 hypervisors shadow page table correctly. Problem found with 64bit Win7 and 32bit XPMode where Win7 switches forth and back between long mode and PAE legacy pagetables.

Quoted 7 lines

Quoted 4 lines
Quoted 1 line
Signed-off-by Christoph Egger <[email protected]>
Don't you have to do this in other cases as well? I think that shadow-on-shadow might need it, at least.
It is needed for all cases where the l1 guest does shadow paging. This includes: Shadow-on-Nested and Shadow-on-Shadow.

I've looked more closely at this and now I'm more confused. :)

Hap-on-hap seems to be OK without it because the special case in paging_gva_to_gfn() does the right thing, using the nestedmode's pt walker.

Why is that not good enough for shadow-on-hap? Is there another path that does unguarded pt walks? If so:
- why is that path not a problem for hap-on-hap; and
- shouldn't that be handled the same way, i.e. either handle everything at lookup time, like paging_gva_to_gfn() does, or handle everything by switching modes at VMRUN/EXIT?

Shadow-on-shadow could potentially be handled the same way as the other configurations, by extending the special case in paging_gva_to_gfn(), but I suspect that a mode switch on VMRUN/EXIT is more likely to Just Work there.

Tim.

Christoph Egger

author

2012-10-04 12:14 UTC #4 lore raw

Quoted 26 lines · Tim Deegan

Quoted 11 lines · Christoph Egger
Quoted 9 lines · Tim Deegan
Quoted 8 lines · Christoph Egger
On VMRUN and VMEXIT emulation update the paging mode for Shadow-on-Nested. This allows Xen to walk the l1 hypervisors shadow page table correctly. Problem found with 64bit Win7 and 32bit XPMode where Win7 switches forth and back between long mode and PAE legacy pagetables.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
Signed-off-by Christoph Egger <[email protected]>
Don't you have to do this in other cases as well? I think that shadow-on-shadow might need it, at least.
It is needed for all cases where the l1 guest does shadow paging. This includes: Shadow-on-Nested and Shadow-on-Shadow.
I've looked more closely at this and now I'm more confused. :)
Hap-on-hap seems to be OK without it because the special case in paging_gva_to_gfn() does the right thing, using the nestedmode's pt walker.

Quoted 6 lines

Why is that not good enough for shadow-on-hap? Is there another path that does unguarded pt walks? If so:
- why is that path not a problem for hap-on-hap; and
- shouldn't that be handled the same way, i.e. either handle everything at lookup time, like paging_gva_to_gfn() does, or handle everything by switching modes at VMRUN/EXIT?

If the l1 guest does not do nested paging then Xen doesn't use the nestedmode's pt walker.

Christoph

Quoted 7 lines

Shadow-on-shadow could potentially be handled the same way as the other configurations, by extending the special case in paging_gva_to_gfn(), but I suspect that a mode switch on VMRUN/EXIT is more likely to Just Work there.
Tim.

Signature · 6 lines

---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

Tim Deegan

2012-10-04 13:23 UTC #5 lore raw

Quoted 36 lines · Christoph Egger

Quoted 26 lines · Tim Deegan
Quoted 11 lines · Christoph Egger
Quoted 9 lines · Tim Deegan
Quoted 8 lines · Christoph Egger
On VMRUN and VMEXIT emulation update the paging mode for Shadow-on-Nested. This allows Xen to walk the l1 hypervisors shadow page table correctly. Problem found with 64bit Win7 and 32bit XPMode where Win7 switches forth and back between long mode and PAE legacy pagetables.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
Signed-off-by Christoph Egger <[email protected]>
Don't you have to do this in other cases as well? I think that shadow-on-shadow might need it, at least.
It is needed for all cases where the l1 guest does shadow paging. This includes: Shadow-on-Nested and Shadow-on-Shadow.
I've looked more closely at this and now I'm more confused. :)
Hap-on-hap seems to be OK without it because the special case in paging_gva_to_gfn() does the right thing, using the nestedmode's pt walker.
Quoted 6 lines
Why is that not good enough for shadow-on-hap? Is there another path that does unguarded pt walks? If so:
- why is that path not a problem for hap-on-hap; and
- shouldn't that be handled the same way, i.e. either handle everything at lookup time, like paging_gva_to_gfn() does, or handle everything by switching modes at VMRUN/EXIT?

Quoted 2 lines

If the l1 guest does not do nested paging then Xen doesn't use the nestedmode's pt walker.

Ah, I was led astray by the nestedhvm_is_n2() check. It turns out that:
nestedhvm_is_n2() returns 0 for guests that are in n2 but aren't hap-on-hap. That's pretty confusing, and I encourage you to change it.

Anyway, I've checked in a modified version of your patch, as
http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a9c84069c248
Please check that it still does what you wanted. :)

Cheers,

Tim.

Christoph Egger

author

2012-10-05 09:07 UTC #6 lore raw

Quoted 40 lines · Tim Deegan

Quoted 36 lines · Christoph Egger
Quoted 26 lines · Tim Deegan
Quoted 11 lines · Christoph Egger
Quoted 9 lines · Tim Deegan
Quoted 8 lines · Christoph Egger
On VMRUN and VMEXIT emulation update the paging mode for Shadow-on-Nested. This allows Xen to walk the l1 hypervisors shadow page table correctly. Problem found with 64bit Win7 and 32bit XPMode where Win7 switches forth and back between long mode and PAE legacy pagetables.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
Signed-off-by Christoph Egger <[email protected]>
Don't you have to do this in other cases as well? I think that shadow-on-shadow might need it, at least.
It is needed for all cases where the l1 guest does shadow paging. This includes: Shadow-on-Nested and Shadow-on-Shadow.
I've looked more closely at this and now I'm more confused. :)
Hap-on-hap seems to be OK without it because the special case in paging_gva_to_gfn() does the right thing, using the nestedmode's pt walker.
Quoted 6 lines
Why is that not good enough for shadow-on-hap? Is there another path that does unguarded pt walks? If so:
- why is that path not a problem for hap-on-hap; and
- shouldn't that be handled the same way, i.e. either handle everything at lookup time, like paging_gva_to_gfn() does, or handle everything by switching modes at VMRUN/EXIT?
Quoted 2 lines
If the l1 guest does not do nested paging then Xen doesn't use the nestedmode's pt walker.

Quoted 7 lines

Ah, I was led astray by the nestedhvm_is_n2() check. It turns out that:
nestedhvm_is_n2() returns 0 for guests that are in n2 but aren't hap-on-hap. That's pretty confusing, and I encourage you to change it.
Anyway, I've checked in a modified version of your patch, as
http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a9c84069c248
Please check that it still does what you wanted. :)

Yes, it does. Thanks.
Please apply it to xen-4.2-testing as well.

Christoph

Signature · 6 lines

---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632