[MODERATED] Re: L1D-Fault KVM mitigation

[Andrew Cooper <andrew.cooper3@citrix.com>]

[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]

On 28/05/2018 07:47, speck for Thomas Gleixner wrote:
> On Sun, 27 May 2018, speck for Andrew Cooper wrote:
>> On 27/05/2018 20:41, speck for Thomas Gleixner wrote:
>>
>> FWIW, my gut feeling at the moment is that the overhead of
>> synchronisation will outweigh disabling hyperthreading, but I'd like to
>> be proved wrong.  Others in the Xen community are looking to extend
>> shadow paging to be as performant as EPT is currently (because at that
>> point, the hypervisor control every PTE accessible to the pagewalk), and
>> again, I'd like to see this succeed, but my gut feeling is that it wont.
> It might be a viable solution for some of the common scenarios like mass
> hosting which tends to have a lot of single vcpu guests; there the overhead
> of shadow page tables might be less than the overhead of forcing siblings
> into idle and putting restrictions on load balancing etc. At least worth to
> investigate.

Sadly, KPTI has taken what as a manageable performance difference
between shadow and EPT, and wrecked it.  A number of common tasks are
between 6 and 16 times slower than EPT, due to all the CR3 vmexits.

The CR3-target feature is attractive because it does let writes to CR3
happen, and can even filter on the NOFLUSH bit being set.  The problem
is the lack of a GPA => HPA translation, so a naive hypervisor which
tries to use this has its guests wandering off their shadows, and
everything explodes.

As of this morning, Juergen and I are experimenting with the hypervisor
providing the translation table to the guest, so it can write the
correctly-translated CR3 and avoid the vmexit.  I've also asked whether
this would be feasible to do in microcode, to avoid having to make any
guest modifications.

~Andrew