Re: [PATCH qemu-web] Add a blog post on "Micro-Optimizing KVM VM-Exits"

[Kashyap Chamarthy]

On Fri, Nov 15, 2019 at 01:45:51PM +0100, Laszlo Ersek wrote:
> On 11/08/19 10:22, Kashyap Chamarthy wrote:

[...]

> > +Guest workloads that are hard to virtualize
> > +-------------------------------------------
> > +
> > +At the 2019 edition of the KVM Forum in Lyon, kernel developer, Andrea
> > +Arcangeli, attempted to address the kernel part of minimizing VM-Exits.
> 
> I'd suggest "addressed", not "attempted to address".

Will fix in next iteration.

[...]

> > +Conclusion
> > +----------

[...]

> > +Although, we still have to deal with mitigations for 'indirect branch
> > +prediction' for a long time, reducing the VM-Exit latency is important
> > +in general; and more specifically, for guest workloads that happen to
> > +trigger frequent VM-Exits, without having to disable Spectre v2
> > +mitigations on the host, as Andrea stated in the cover letter of his
> > +patch series.
> > 
> 
> This article refers to "indirect calls" and "indirect branches" quite a
> few times.
> 
> I suggest mentioning "function pointers" at least once...
> 
> (AIUI, the core of the issue is that kvm.ko calls kvm-intel.ko and
> kvm-amd.ko through function pointers. Such calls are the target of
> malicious branch predictor mis-training, and therefore, as a
> counter-measure, they are compiled into retpolines, rather than the
> directly corresponding indirect call assembly instructions. But
> retpolines run slowly, in comparison. Calling the functions in question
> by name, in the C source code, rather than via function pointers,
> eliminates the indirect call assembly instructions, and obviates the
> need for retpolines. The resultant C source code is less abstract and
> less dynamic at runtime, but the original indirection isn't inherently
> necessary at runtime.)
> 
> I couldn't attend Andrea's presentation, nor have I seen the slides, or
> a recording thereof, or the patchset; so I could easily be off. 

I think your above explanation is indeed correct (which I couldn't have
articulated so well; thanks!), based on my understanding, and reading
Andrea's patch[*] and its commit message:

    "This [patch] replaces all kvm_x86_ops pointer to functions with
    regular external functions that don't require indirect calls.

    "[...] The pointer to function virtual template model cannot provide
    any runtime benefit because kvm-intel and kvm-amd can't be loaded at
    the same time. [...]"


[*] https://lkml.org/lkml/2019/9/20/932 --  [PATCH 02/17] KVM:
    monolithic: x86: convert the kvm_x86_ops methods to external functions

> My point is, *if* the expression "function pointers" applies in this
> context, please do mention it; otherwise "indirect calls" just hangs
> in the air, IMHO.
> 
> It might be as simple as replacing
> 
>   These indirect calls were not optimal before,
> 
> with
> 
>   These indirect calls -- via function pointers in the C source code
>   -- were not optimal before,

Will fix; thanks for the thorough review.

If you want to read Andrea's slides, here they are:

    https://static.sched.com/hosted_files/kvmforum2019/3b/kvm-monolithic.pdf

Thanks for the review!

-- 
/kashyap