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

Re: [Xen-devel] [PATCH 19/27] x86/hvm: Use per-domain policy information in hvm_cpuid()



>>> On 04.01.17 at 13:39, <andrew.cooper3@xxxxxxxxxx> wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3335,39 +3335,33 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
> unsigned int *ebx,
>          *ebx &= 0x00FFFFFFu;
>          *ebx |= (v->vcpu_id * 2) << 24;
>  
> -        *ecx &= hvm_featureset[FEATURESET_1c];
> -        *edx &= hvm_featureset[FEATURESET_1d];
> +        *ecx = p->basic._1c;
> +        *edx = p->basic._1d;
>  
>          /* APIC exposed to guests, but Fast-forward MSR_APIC_BASE.EN back 
> in. */
>          if ( vlapic_hw_disabled(vcpu_vlapic(v)) )
>              *edx &= ~cpufeat_bit(X86_FEATURE_APIC);
>  
> -        /* OSXSAVE cleared by hvm_featureset.  Fast-forward CR4 back in. */
> +        /* OSXSAVE clear in policy.  Fast-forward CR4 back in. */
>          if ( v->arch.hvm_vcpu.guest_cr[4] & X86_CR4_OSXSAVE )
>              *ecx |= cpufeat_mask(X86_FEATURE_OSXSAVE);
>  
> -        /* Don't expose HAP-only features to non-hap guests. */
> -        if ( !hap_enabled(d) )
> -        {
> -            *ecx &= ~cpufeat_mask(X86_FEATURE_PCID);
> -
> -            /*
> -             * PSE36 is not supported in shadow mode.  This bit should be
> -             * unilaterally cleared.
> -             *
> -             * However, an unspecified version of Hyper-V from 2011 refuses
> -             * to start as the "cpu does not provide required hw features" if
> -             * it can't see PSE36.
> -             *
> -             * As a workaround, leak the toolstack-provided PSE36 value into 
> a
> -             * shadow guest if the guest is already using PAE paging (and
> -             * won't care about reverting back to PSE paging).  Otherwise,
> -             * knoble it, so a 32bit guest doesn't get the impression that it
> -             * could try to use PSE36 paging.
> -             */
> -            if ( !(hvm_pae_enabled(v) || hvm_long_mode_enabled(v)) )
> -                *edx &= ~cpufeat_mask(X86_FEATURE_PSE36);
> -        }
> +        /*
> +         * PSE36 is not supported in shadow mode.  This bit should be
> +         * unilaterally cleared.
> +         *
> +         * However, an unspecified version of Hyper-V from 2011 refuses
> +         * to start as the "cpu does not provide required hw features" if
> +         * it can't see PSE36.
> +         *
> +         * As a workaround, leak the toolstack-provided PSE36 value into a
> +         * shadow guest if the guest is already using PAE paging (and won't
> +         * care about reverting back to PSE paging).  Otherwise, knoble it, 
> so
> +         * a 32bit guest doesn't get the impression that it could try to use
> +         * PSE36 paging.
> +         */
> +        if ( !hap_enabled(d) && !(hvm_pae_enabled(v) || 
> hvm_long_mode_enabled(v)) )
> +            *edx &= ~cpufeat_mask(X86_FEATURE_PSE36);

The PSE36 part of this is fine, bit the PCID dropping (as well as the
PKU part below) made me go look back at patch 7: You AND together
hvm_max_policy.fs[] and hvm_shadow_featuremask[], which aren't
quite the same (the equivalent of the latter would be
hvm_hap_featuremask[]). Aren't we risking to wrongly hide features
in shadow mode this way, at least as soon as max != default?

Since that would rather affect the other patch, this one is
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan


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

 


Rackspace

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