[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 08/10/13 09:45, Jan Beulich wrote: On 07.10.13 at 18:12, Tim Deegan <tim@xxxxxxx> 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>And indeed I'm rather puzzled by the simplistic re-use of a PV construct: There are memory management related bits in CR4, and with memory management not being PV for PVH guests, this seems conceptually wrong. What would be a better approach, do you think? -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |