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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 05/01/17 12:55, Jan Beulich wrote:
>>>> 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?

hvm_shadow_featuremask[] is strictly a subset of hvm_hap_featuremask[],
by virtue of A/S/H annotations in cpufeatureset.h

hvm_max_policy.fs[] is most likely the HAP set, but might be Shadow if
HAP is entirely unavailable on the host.

I don't forsee a situation where shadow would ever be more featureful
than hap.  The only differences are paging related features.

~Andrew

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