[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 0/9] xen/amd: Support for guest MSR_VIRT_SPEC_CTRL support
>>> On 03.12.18 at 17:31, <andrew.cooper3@xxxxxxxxxx> wrote: > On 03/12/2018 16:24, Jan Beulich wrote: >>>>> On 03.12.18 at 17:18, <andrew.cooper3@xxxxxxxxxx> wrote: >>> This is a lingering TODO item from XSA-263. It adds support AMD's >>> MSR_VIRT_SPEC_CTRL interface, and changes Xen's "boot time global" SSBD >>> setting into a per-vcpu setting. >>> >>> This can be found on: >>> git://xenbits.xen.org/people/andrewcoop/xen.git xen-virt-spec-ctrl-v1 >>> >>> The start of the series is some cleanup. It then teaches Xen to recognise > the >>> available interfaces (including MSR_VIRT_SPEC_CTRL from a hypervisor), then >>> how to safely context switch the per-core LS_CFG on Fam17h, an finally to >>> expose support to guests. >>> >>> I've got some further MSR work coming because we have to fix the >>> default-leakiness of MSRs in this range, because a guest becomes unsafe to >>> migrate as soon as it reads any of the pipeline control MSRs. >> I've seen you mention this elsewhere, but I'm still unclear about >> the "why" part here. > > Because the existence (or not) are model specific, the details read are > non-architectural, not always the same on minor variations of the same > platform, and definitely not the same across different models. But migration then is only one (albeit perhaps the major) aspect. CPUID overrides altering e.g. the model number would similarly be a problem if we were to imply from reads of these MSRs that "problematic" conclusions would be drawn by the guest. Otoh I can't see how migration to an identical CPU model system would become unsafe. Nor can I see how hiding these MSRs from guests would improve the situation in this regard: Guests may still draw unwanted conclusions from not being able to read these MSRs, or reading all zeros. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |