Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 26 Aug 2022 15:08:28 +0000
From:   Sean Christopherson <seanjc@google.com>
To:     Xiaoyao Li <xiaoyao.li@intel.com>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Jiri Olsa <jolsa@kernel.org>,
        Namhyung Kim <namhyung@kernel.org>,
        Paolo Bonzini <pbonzini@redhat.com>,
        linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
        kvm@vger.kernel.org
Subject: Re: [RFC PATCH 2/2] KVM: VMX: Stop/resume host PT before/after VM
 entry when PT_MODE_HOST_GUEST
Message-ID: <YwjhaPdvmklwXf9B@google.com>
References: <20220825085625.867763-1-xiaoyao.li@intel.com>
 <20220825085625.867763-3-xiaoyao.li@intel.com>
 <YweWmF3wMPRnthIh@google.com>
 <6bcab33b-3fde-d470-88b9-7667c7dc4b2d@intel.com>
 <YwecducnM/U6tqJT@google.com>
 <4e383b85-6777-4452-a073-4d2f439e28b1@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4e383b85-6777-4452-a073-4d2f439e28b1@intel.com>
Precedence: bulk

On Fri, Aug 26, 2022, Xiaoyao Li wrote:
> On 8/25/2022 11:59 PM, Sean Christopherson wrote:
> > But ensuring the RTIT_CTL.TraceEn=0 is all that's needed to make VM-Entry happy,
> > and if the host isn't using Intel PT, what do we care if other bits that, for all
> > intents and purposes are ignored, are lost across VM-Entry/VM-Exit?  I gotta
> > imaging the perf will fully initialize RTIT_CTL if it starts using PT.
> 
> Personally, I agree with it.
> 
> But I'm not sure if there is a criteria that host context needs to be
> unchanged after being virtualized.
> 
> > Actually, if the host isn't actively using Intel PT, can KVM avoid saving the
> > other RTIT MSRs?
> 
> I don't think it's a good idea that it requires PT driver never and won't
> rely on the previous value of PT MSRs. But it's OK if handing it over to
> perf as the idea you gave below.

Yep, my thought exactly.

> > Even better, can we hand that off to perf?  I really dislike KVM making assumptions
> > about perf's internal behavior.  E.g. can this be made to look like
> 
> you mean let perf subsystem to do the context save/restore staff of host and
> KVM focuses on save/restore of guest context, right?

Yep!  KVM already more or less does this for "regular" PMU MSRs, though in that
case perf hands back a list of MSRs+data.  But for Intel PT I don't see any point
in having KVM do the actual MSR accesses.  Tracing has to be turned off _before_
VM-Enter, so using the MSR load/save lists doesn't buy us anything. 
 
> I would like to see comment from perf folks on this and maybe need their
> help on how to implement.