On 16/05/2019 03:46, wencongyang (A) wrote: > Hi all > > Fill buffers, load ports are shared between threads on the same physical core. > We need to run more than one vm on the same physical core. > Is there any complete mitigation for environments utilizing SMT?
No - not really. An approach which was worked on was that of synchronised scheduling, whereby privilege transitions are syncrhonised to ensure that we're never running code from different privilege levels concurrently on adjacent threads. (This is the mitigation described as Group Scheduling in https://software.intel.com/security-software-guidance/insights/deep-dive-intel-analysis-microarchitectural-data-sampling ) However... First of all, it depends on core scheduling as a prerequisite, and as you can see, that is still a work-in-progress for Xen. There are many other good reasons for doing core scheduling, so we will be continuing with that work. For partners who already had core scheduling and experimented with synchronised scheduling, no-one found a way of making it function with less overhead than disabling hyperthreading in the first place. This was was a native OS case - the virtualised case gets a compound performance hit because every time the guest kernel tries to synchronise, it forces Xen to synchronise, because there is no virtualisation of IPIs available in affected hardware. Overall, it looks like the one mitigation option which would allow hyperthreading to remain active had a larger performance penalty than disabling hyperthreading (on native, and remember that it is compounded when virtualised), and is a very invasive change to the entry/exit code. Unless someone finds a really clever alternative plan, there doesn't appear to be a viable alternative to turning off hyperthreading when cross-thread leakage is a concern. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
