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

Re: [Xen-devel] [PATCH v2] Nested VMX: CR emulation fix up



>>> On 29.10.13 at 06:10, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> wrote:
> Current code seems a little redundant. I revised it to put the redundant 
> code into nvmx_set_cr_read_shadow(). Please review it.
> 
> void nvmx_set_cr_read_shadow(struct vcpu *v, unsigned int cr)
> {
>     unsigned long cr_field, read_shadow_field, mask_field;
> 
>     switch ( cr )
>     {
>     case 0: 
>         cr_field = GUEST_CR0;
>         read_shadow_field = CR0_READ_SHADOW;
>         mask_field = CR0_GUEST_HOST_MASK;
>         break;
>     case 4:
>         cr_field = GUEST_CR4;
>         read_shadow_field = CR4_READ_SHADOW;
>         mask_field = CR4_GUEST_HOST_MASK;
>         break;
>     default:
>         gdprintk(XENLOG_WARNING, "Set read shadow for CR%d.\n", cr);
>         return;
>     }
> 
>     if ( !nestedhvm_vmswitch_in_progress(v) )
>     {
>         unsigned long virtual_cr_mask = 
>             __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, mask_field);
> 
>         /*
>          * We get here when L2 changed cr in a way that did not change
>          * any of L1's shadowed bits (see nvmx_n2_vmexit_handler),
>          * but did change L0 shadowed bits. So we first calculate the
>          * effective cr value that L1 would like to write into the
>          * hardware. It consists of the L2-owned bits from the new
>          * value combined with the L1-owned bits from L1's guest cr.
>          */
>         v->arch.hvm_vcpu.guest_cr[cr] &= ~virtual_cr_mask;
>         v->arch.hvm_vcpu.guest_cr[cr] |= virtual_cr_mask &
>             __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, cr_field);
>     }
> 
>     /* nvcpu.guest_cr is what L2 write to cr actually. */
>     __vmwrite(read_shadow_field, v->arch.hvm_vcpu.nvcpu.guest_cr[cr]);
> }

This looks quite a bit cleaner in any event, and I'm certainly in
favor of eliminating unnecessary redundancy.

Jan


_______________________________________________
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®.