[MODERATED] Re: L1D-Fault KVM mitigation

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

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

On 27/05/2018 20:41, speck for Thomas Gleixner wrote:
> On Sun, 27 May 2018, speck for Linus Torvalds wrote:
>> On Sun, 27 May 2018, speck for Andrew Cooper wrote:
>>> Xen doesn't ever vcpus enter idle themselves.  We trap HLT/etc and will
>>> either schedule another VM, or choose to idle the host if there really
>>> is nothing else to do.
>> Right. But then there is never any such thing as "guest idle". There is 
>> only "host idle" or "host is doing something else entirely".
>>
>> You _could_ have a "idle polling" mode which is separate from the regular 
>> host idle loop, I guess.
>>
>>> I've never come across a plausible usecase for letting non-root mode
>>> idle the cores into a low power state.  They simply aren't in a position
>>> to know whether other work needs doing or not.
>> Afaik, it mainly makes sense when there is no actual host OS at all, just 
>> the bare-metal hypervisor used for partitioning resources, not scheduling 
>> them.
> Right. That's what the Jailhouse hypervisor does. It's a zero vmexit setup.

Jailhouse also has static assignment of resources, which means they can
arrange never to have two different VMs on the same sibling hyperthreads.

They still need to disable hyperthreads or find a working
synchronisation algorithm for entry/exit, but they don't have the added
gang scheduling problem of ensuring that two hyperthreads are always
occupied by vcpus of the same VM.

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.

~Andrew