Re: [PATCH] KVM: x86: Track supported ARCH_CAPABILITIES in kvm_caps

[Sean Christopherson]

On Mon, May 29, 2023, Chao Gao wrote:
> On Thu, May 18, 2023 at 10:33:15AM -0700, Sean Christopherson wrote:
> >FWIW, this trainwreck is another reason why I'm not going to look at the proposed
> >"Intel IA32_SPEC_CTRL Virtualization" crud until external forces dictate that I
> >do so.  I have zero confidence that a paravirt interface defined by hardware
> >vendors to fiddle with mitigations will be sane, flexible, and extensible.
> 
> Hi Sean,
> 
> Just to confirm we are on the same page:
> 
> "Intel IA32_SPEC_CTRL Virtualization" series consists of 3 parts:
> 
> 1. Expose BHI_CTRL, RRSBA_CTRL to guests. They are hardware mitigations to
>    disable BHI and RRSBA behaviors and can be used by both guest/host.
> 
> 2. Enable IA32_SPEC_CTRL Virtualization which is a VMX feature. This is for KVM
>    to effectively lock some bits of IA32_SPEC_CTRL MSR when guests are running.
> 
> 3. Implement the paravirt interface (the virtual MSRs) for guests to report
>    software mitigations in-use. KVM can utilize such information to enable
>    hardware mitigations for guests transparently to address software mitigation
>    effectiveness issues caused by CPU microarchitecture changes (RRSBA behavior,
>    size of branch history table).
> 
> As per my understanding, your concerns are primarily focused on #3, the
> paravirt interface, rather than the entire series. Am I correct in assuming that
> you do not oppose #1 and #2?

Yes, correct.  I definitely recommend posting #1 and #2 separately from the
paravirt interface, I ignored the entire series without realizing there is real
hardware support in there.

> You previously mentioned that the paravirt interface was not common [1], and
> this time, you expressed an expectation for the interface to be "sane, flexible,
> and extensible." To ensure clarity, I want to confirm my interpretation of
> your expectations:
> 
> 1. The interface should not be tied to a specific CPU vendor but instead be
>    beneficial for Intel and AMD (and even ARM, and potentially others).
> 
> 2. The interface should have the capability to solve other issues (e.g,
>    coordinate mitigations in guest/host to address other perf/function issues),
>    not limited to software mitigation effectiveness on Intel CPUs.
> 3. The interface should be extendable by VMMs rather than relying on hardware
>    vendors rolling out new spec. This enables VMM developers to propose new
>    ideas to coordinate mitigations in guest/host.

Ya, that's more or less my opinion.  Even more than allowing VMM developers to
extend/define the interface, I want the definition of the interace to be a
community/collaborative effort.  LKML has active representatives from all of the
major (known) hypervisors, so it shouldn't be *that* hard to figure out a way to
make the interface community driven.

Note that it doesn't necessarily have to be VMM developers, e.g. many of the
people that are intimately familiar with the mitigations aren't virtualization
folks.

> Please let me know if I missed any key points or if any of the above statements
> do not align with your expectations. 
> 
> [1]: https://lore.kernel.org/all/Y6Sin1bmLN10yvMw@xxxxxxxxxx/