[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5D2406AC.20402@intel.com>
Date: Tue, 09 Jul 2019 11:14:52 +0800
From: Wei Wang <wei.w.wang@...el.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
pbonzini@...hat.com, ak@...ux.intel.com, kan.liang@...el.com,
mingo@...hat.com, rkrcmar@...hat.com, like.xu@...el.com,
jannh@...gle.com, arei.gonglei@...wei.com, jmattson@...gle.com
Subject: Re: [PATCH v7 10/12] KVM/x86/lbr: lazy save the guest lbr stack
On 07/08/2019 10:53 PM, Peter Zijlstra wrote:
> On Mon, Jul 08, 2019 at 09:23:17AM +0800, Wei Wang wrote:
>> When the vCPU is scheduled in:
>> - if the lbr feature was used in the last vCPU time slice, set the lbr
>> stack to be interceptible, so that the host can capture whether the
>> lbr feature will be used in this time slice;
>> - if the lbr feature wasn't used in the last vCPU time slice, disable
>> the vCPU support of the guest lbr switching.
>>
>> Upon the first access to one of the lbr related MSRs (since the vCPU was
>> scheduled in):
>> - record that the guest has used the lbr;
>> - create a host perf event to help save/restore the guest lbr stack;
>> - pass the stack through to the guest.
> I don't understand a word of that.
>
> Who cares if the LBR MSRs are touched; the guest expects up-to-date
> values when it does reads them.
Another host thread who shares the same pCPU with this vCPU thread
may use the lbr stack, so the host needs to save/restore the vCPU's lbr
state.
Otherwise the guest perf inside the vCPU wouldn't read the correct data
from the lbr msr (as the msrs are changed by another host thread already).
As Andi also replied, if the vCPU isn't using lbr anymore, host doesn't need
to save the lbr msr then.
Best,
Wei
Powered by blists - more mailing lists