From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
Subject: Re: [PATCH RFC v13 06/20] pvh: vmx-specific changes
Date: Mon, 7 Oct 2013 17:55:28 +0200
Message-ID: <5252D970.3050802@citrix.com>
References: <1379955000-11050-1-git-send-email-george.dunlap@eu.citrix.com>
	<1379955000-11050-7-git-send-email-george.dunlap@eu.citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <1379955000-11050-7-git-send-email-george.dunlap@eu.citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: George Dunlap <george.dunlap@eu.citrix.com>
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

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)