[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |