[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 for-4.10] x86: Avoid corruption on migrate for vcpus using CPUID Faulting
On 27/11/17 14:41, Jan Beulich wrote: >>>> On 27.11.17 at 14:02, <andrew.cooper3@xxxxxxxxxx> wrote: >> Xen 4.8 and later virtualises CPUID Faulting support for guests. However, >> the >> value of MSR_MISC_FEATURES_ENABLES is omitted from the vcpu state, meaning >> that the current cpuid faulting setting is lost on migrate/suspend/resume. >> >> To move this MSR, use the new guest_{rd,wr}msr() infrastructure. This avoids >> duplicating or opencoding the feature check and value logic, as well as >> abstracting away the internal value representation. One small adjustment to >> guest_wrmsr() is required to cope with being called in toolstack context. >> >> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> > With the further intentions mentioned in the description (as a > justification for some of the earlier requested changes to not > be done), as indicated in a late response to v1 > Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> I thought that was already clear from the second paragraph. Either way, how about this? Xen 4.8 and later virtualises CPUID Faulting support for guests. However, the value of MSR_MISC_FEATURES_ENABLES is omitted from the vcpu state, meaning that the current cpuid faulting setting is lost on migrate/suspend/resume. Instead of following the MSR status quo, take the opportunity to make the logic more generic, and in particular, trivial to extend for future MSRs. This is done by discarding the notion of optional MSRs, and requiring the toolstack to be prepared to move all of the MSRs, although only a subset will typically need to move. This allows for the use of guest_{rd,wr}msr() alone to evaluate whether an MSR needs moving. This is a benefit because it means there is a single piece of logic responsible for evaluating whether a guest can use an MSR, and which values are acceptable. One small adjustment to guest_wrmsr() is required to cope with being called in toolstack context. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |