[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH qemu-web] Add a blog post on "Micro-Optimizing KVM VM-Exits"
From: |
Kashyap Chamarthy |
Subject: |
Re: [PATCH qemu-web] Add a blog post on "Micro-Optimizing KVM VM-Exits" |
Date: |
Fri, 15 Nov 2019 16:27:39 +0100 |
User-agent: |
Mutt/1.12.1 (2019-06-15) |
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