Re: [PATCH v7 08/12] KVM/x86/vPMU: Add APIs to support host save/restore the guest lbr stack

[Wei Wang]

On 07/08/2019 10:48 PM, Peter Zijlstra wrote:
> On Mon, Jul 08, 2019 at 09:23:15AM +0800, Wei Wang wrote:
> > From: Like Xu <like.xu@xxxxxxxxx>
> >
> > This patch adds support to enable/disable the host side save/restore
> This patch should be disqualified on Changelog alone...
>
>    Documentation/process/submitting-patches.rst:instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy

OK, we will discard "This patch" in the description:

To enable/disable the host side save/restore for the guest lbr stack on
vCPU switching, the host creates a perf event for the vCPU..

> > for the guest lbr stack on vCPU switching. To enable that, the host
> > creates a perf event for the vCPU, and the event attributes are set
> > to the user callstack mode lbr so that all the conditions are meet in
> > the host perf subsystem to save the lbr stack on task switching.
> >
> > The host side lbr perf event are created only for the purpose of saving
> > and restoring the lbr stack. There is no need to enable the lbr
> > functionality for this perf event, because the feature is essentially
> > used in the vCPU. So perf_event_create is invoked with need_counter=false
> > to get no counter assigned for the perf event.
> >
> > The vcpu_lbr field is added to cpuc, to indicate if the lbr perf event is
> > used by the vCPU only for context switching. When the perf subsystem
> > handles this event (e.g. lbr enable or read lbr stack on PMI) and finds
> > it's non-zero, it simply returns.
> *WHY* does the host need to save/restore? Why not make VMENTER/VMEXIT do
> this?

Because the VMX transition is much more frequent than the vCPU switching.
On SKL, saving 32 LBR entries could add 3000~4000 cycles overhead, this
would be too large for the frequent VMX transitions.

LBR state is saved when vCPU is scheduled out to ensure that this vCPU's
LBR data doesn't get lost (as another vCPU or host thread that is 
scheduled in
may use LBR)


> Many of these patches don't explain why things are done; that's a
> problem.

We'll improve, please help when you find anywhere isn't clear to you, 
thanks.

Best,
Wei