[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC v13 06/20] pvh: vmx-specific changes
At 17:20 +0100 on 07 Oct (1381166400), George Dunlap wrote: > On 07/10/13 17:12, Tim Deegan wrote: > >At 17:06 +0100 on 07 Oct (1381165615), George Dunlap wrote: > >>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. > ><harping on> This is the sort of thing that would be easier if PVH guests > >were just HVM ones with extra hypercalls. <harping off> > > I'm not sure this would have helped -- the issue here is that we start > the guest with long mode and paging enabled, which I think is something > we want to do (rather than having to start in 16-bit mode and level-up > through 32-bit to 64-bit mode). To do that, Mukesh very reasonably > began by setting the guest cr4 to what a PV guest would see of the cr4, > and for him it worked -- apparently because his PVH Linux doesn't touch > cr4. Sure. But if we used the existing HVM state-setting hypercalls to build PVH guests, they would DTRT and return an error to the builder. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |