[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC v13 06/20] pvh: vmx-specific changes



On 07/10/13 16:55, Roger Pau Monné wrote:
On 23/09/13 18:49, George Dunlap wrote:
@@ -1028,12 +1129,28 @@ static int construct_vmcs(struct vcpu *v)
                | (1U << TRAP_no_device);
      vmx_update_exception_bitmap(v);
+ /* In HVM domains, this happens on the realmode->paging
+     * transition.  Since PVH never goes through this transition, we
+     * need to do it at start-of-day. */
+    if ( is_pvh_domain(d) )
+        vmx_update_debug_state(v);
+
      v->arch.hvm_vcpu.guest_cr[0] = X86_CR0_PE | X86_CR0_ET;
+
+    /* PVH domains always start in paging mode */
+    if ( is_pvh_domain(d) )
+        v->arch.hvm_vcpu.guest_cr[0] |= X86_CR0_PG | X86_CR0_NE | X86_CR0_WP;
+
      hvm_update_guest_cr(v, 0);
- v->arch.hvm_vcpu.guest_cr[4] = 0;
+    v->arch.hvm_vcpu.guest_cr[4] = is_pvh_domain(d) ?
+        real_cr4_to_pv_guest_cr4(mmu_cr4_features)
Here we need to mask the bits in CR4 that the guest isn't allowed to
set. Right now Xen is setting the VMXE bit by default, which the guest
is not able to modify, so if the guests tries to update CR4 based on the
previous value Xen is going to complain:

+        real_cr4_to_pv_guest_cr4(mmu_cr4_features) &
+        ~HVM_CR4_GUEST_RESERVED_BITS(v)

Thanks for testing that -- I'll include it in the next spin-up.

I'll probably also add a patch ASSERT'ing at the end of this function that the guest CR values have no reserved bits set.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.