[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 11/30] xen/x86: Calculate maximum host and guest featuresets
On 15/02/16 15:07, Jan Beulich wrote: > >>>> +uint32_t __read_mostly raw_featureset[FSCAPINTS]; >>>> +uint32_t __read_mostly host_featureset[FSCAPINTS]; >>>> +uint32_t __read_mostly pv_featureset[FSCAPINTS]; >>>> +uint32_t __read_mostly hvm_featureset[FSCAPINTS]; >>>> + >>>> +static void sanitise_featureset(uint32_t *fs) >>>> +{ >>>> + unsigned int i; >>>> + >>>> + for ( i = 0; i < FSCAPINTS; ++i ) >>>> + { >>>> + /* Clamp to known mask. */ >>>> + fs[i] &= known_features[i]; >>>> + } >>>> + >>>> + switch ( boot_cpu_data.x86_vendor ) >>>> + { >>>> + case X86_VENDOR_INTEL: >>>> + /* Intel clears the common bits in e1d. */ >>>> + fs[FEATURESET_e1d] &= ~COMMON_1D; >>>> + break; >>>> + >>>> + case X86_VENDOR_AMD: >>>> + /* AMD duplicates the common bits between 1d and e1d. */ >>>> + fs[FEATURESET_e1d] = ((fs[FEATURESET_1d] & COMMON_1D) | >>>> + (fs[FEATURESET_e1d] & ~COMMON_1D)); >>>> + break; >>>> + } >>> How is this meant to work with cross vendor migration? >> I don't see how cross-vendor is relevant here. This is about reporting >> the hosts modified featureset accurately to the toolstack. > I.e. you're not later going to use what you generate here to also > massage (or at least validate) what guests are going to see? Oh right - as currently implemented, this will clobber features on an Intel host attempting to emulate AMD through cross-vendor. I will reconsider the logic in v3. This isn't trivial to fix, especially given that we don't yet have per-domain policies. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |