From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9C0C8ECAAA5 for ; Mon, 29 Aug 2022 17:33:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231445AbiH2Rdw (ORCPT ); Mon, 29 Aug 2022 13:33:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59448 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230077AbiH2Rdt (ORCPT ); Mon, 29 Aug 2022 13:33:49 -0400 Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 147AA97EDA for ; Mon, 29 Aug 2022 10:33:48 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id bh13so8309395pgb.4 for ; Mon, 29 Aug 2022 10:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc; bh=88XtoZzbZveGIe6W4F/YHkUpeXUSRoxhWtsQ1gJLO0Y=; b=LJaqQyLKxs3mDeGI+elBZm8fcrM3+d/GXgdgigp63emskLM21WywFzIxpfkbNzbC3o FRzay+TVzn8Cjiy4vOeVRnbGm1Gzfol1Ot+N1DHPmmcXwiPMhujmj2t1pHgn59u6TCeV xSeIdUN0aD0RSqbzf+I3Zu1jGphrLU3Jltrr08erMtzDVSQk9eVn3YZCpmZ8Wq2nmLjC HWo2WyeWeREOYPY4AnAhy7IHESg8Bb4YMydbQENy9XLXjSA+UvZxl3lL9aLxbJjhq/bU sc7A4wHo/Z3npb0nGdYKfPWUKi3yqO1DOEFaleDRCqhWnMuLLMsXSBV0bGKa5Ywgts0d IBBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=88XtoZzbZveGIe6W4F/YHkUpeXUSRoxhWtsQ1gJLO0Y=; b=A+pHSqLYt50Adp7o7OuUnnPaHr1V66+jaSMW/rDwbBb0W2t56wQVAKxkI0bX902z0F O1CTBVpNF9RKeSG8VmWUAD5hyE3Bo3//L9SZjyRX9jN2546I0uDNk6ebkHJI25j0fZMK ctWDn9ZIAdGGWnB/vhxR8G0v1ylE/4RR7bvxQunPMspLR4COGZgWfNQlB4OWlhZMls8D D2eIdfOi/VDHsuiDzqG20CU9WrqCvlGwQh4NrRbmBl1LcU1EArSCpqCiuUEdRJpdTVRM SuOQUXExtHY4Rbrl9lVFhSC4e80u9qa9MlVzpzq2qIR1aR6VYh6iB39UrUVIi9yD+m+s 9xsA== X-Gm-Message-State: ACgBeo17UT8qRgHowUJbzszezT3b8P52eLMFiCaFzYrsOJ7XdZ1pWr/U Rg9Ve7kklYNcquhCqlHifqfWVA== X-Google-Smtp-Source: AA6agR7q8oP/7KryicESNNPbuoFC/Z6Q/8/57egou/NQwmyr6L/ZlgPZUyO3Dw4sca0Zgib8B5HGVg== X-Received: by 2002:a65:4c07:0:b0:427:bbde:99c with SMTP id u7-20020a654c07000000b00427bbde099cmr14892722pgq.390.1661794426448; Mon, 29 Aug 2022 10:33:46 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id oo16-20020a17090b1c9000b001fd7e56da4csm5201876pjb.39.2022.08.29.10.33.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Aug 2022 10:33:46 -0700 (PDT) Date: Mon, 29 Aug 2022 17:33:42 +0000 From: Sean Christopherson To: "Wang, Wei W" Cc: "Li, Xiaoyao" , Peter Zijlstra , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Paolo Bonzini , "linux-perf-users@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" Subject: Re: [RFC PATCH 0/2] KVM: VMX: Fix VM entry failure on PT_MODE_HOST_GUEST while host is using PT Message-ID: References: <20220825085625.867763-1-xiaoyao.li@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 29, 2022, Wang, Wei W wrote: > On Thursday, August 25, 2022 4:56 PM, Xiaoyao Li wrote: > #if defined(CONFIG_PERF_EVENTS) && defined(CONFIG_CPU_SUP_AMD) > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > index d7f8331d6f7e..195debc1bff1 100644 > --- a/arch/x86/kvm/vmx/vmx.c > +++ b/arch/x86/kvm/vmx/vmx.c > @@ -1125,37 +1125,29 @@ static inline void pt_save_msr(struct pt_ctx *ctx, u32 addr_range) > > static void pt_guest_enter(struct vcpu_vmx *vmx) > { > - if (vmx_pt_mode_is_system()) > + struct perf_event *event; > + > + if (vmx_pt_mode_is_system() || > + !(vmx->pt_desc.guest.ctl & RTIT_CTL_TRACEEN)) I don't think the host should trace the guest in the host/guest mode just because the guest isn't tracing itself. I.e. the host still needs to turn off it's own tracing. > return; > > - /* > - * GUEST_IA32_RTIT_CTL is already set in the VMCS. > - * Save host state before VM entry. > - */ > - rdmsrl(MSR_IA32_RTIT_CTL, vmx->pt_desc.host.ctl); > - if (vmx->pt_desc.guest.ctl & RTIT_CTL_TRACEEN) { > - wrmsrl(MSR_IA32_RTIT_CTL, 0); > - pt_save_msr(&vmx->pt_desc.host, vmx->pt_desc.num_address_ranges); > - pt_load_msr(&vmx->pt_desc.guest, vmx->pt_desc.num_address_ranges); > - } > + event = pt_get_curr_event(); > + perf_event_disable(event); > + vmx->pt_desc.host_event = event; This is effectively what I suggested[*], the main difference being that my version adds dedicated enter/exit helpers so that perf can skip save/restore of the other MSRs. It's easy to extend if perf needs to hand back an event to complete the "exit. bool guest_trace_enabled = vmx->pt_desc.guest.ctl & RTIT_CTL_TRACEEN; vmx->pt_desc.host_event = intel_pt_guest_enter(guest_trace_enabled); and then on exit bool guest_trace_enabled = vmx->pt_desc.guest.ctl & RTIT_CTL_TRACEEN; intel_pt_guest_exit(vmx->pt_desc.host_event, guest_trace_enabled); [*] https://lore.kernel.org/all/YwecducnM%2FU6tqJT@google.com > + pt_load_msr(&vmx->pt_desc.guest, vmx->pt_desc.num_address_ranges); > }