On 04/12/2018 09:45, Jan Beulich wrote: >>>> On 03.12.18 at 17:31, <andrew.coop...@citrix.com> wrote: >> On 03/12/2018 16:24, Jan Beulich wrote: >>>>>> On 03.12.18 at 17:18, <andrew.coop...@citrix.com> 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.
Identical system with identical firmware and configuration - yes we'd expect them to have identical values in these configuration. > > 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. I can't help but feel that the observations you've made answer the question very succinctly. Of course we can't prevent the guest drawing conclusions from the absense/presence of the information. What we can (and must) ensure is that the information that is available (i.e. a #GP fault) does not have any details which are specific to the processor that the VM happened to boot on. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
