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;
From:   "Wang, Wei W" <wei.w.wang@intel.com>
To:     "Christopherson,, Sean" <seanjc@google.com>
CC:     "Li, Xiaoyao" <xiaoyao.li@intel.com>,
        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-perf-users@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "kvm@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
Thread-Topic: [RFC PATCH 0/2] KVM: VMX: Fix VM entry failure on
 PT_MODE_HOST_GUEST while host is using PT
Thread-Index: AQHYuGCfKwYxaXR4306din/WULaC4K3Fff5wgACsNwCAAJww0A==
Date:   Tue, 30 Aug 2022 06:02:31 +0000
Message-ID: <CY5PR11MB6365E7E07AB03F3675543717DC799@CY5PR11MB6365.namprd11.prod.outlook.com>
References: <20220825085625.867763-1-xiaoyao.li@intel.com>
 <CY5PR11MB6365897E8E6D0B590A298FA0DC769@CY5PR11MB6365.namprd11.prod.outlook.com>
 <Ywz4diMZBB7DdITb@google.com>
In-Reply-To: <Ywz4diMZBB7DdITb@google.com>
Accept-Language: en-US
Content-Language: en-US
dlp-product: dlpe-windows
dlp-reaction: no-action
dlp-version: 11.6.500.17
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?b1H9F0PZyU+05hCn8D7JLU2uQwspnBmmfp0YatuWHGV1+KusMXrU29WwXbeo?=
 =?us-ascii?Q?8OXaSdeL+91jeVlamNMawHogwFZIDphR9/CpPuUKYM1E7RQNnPvubQzfwTKy?=
 =?us-ascii?Q?3OVlXU3ljWJW47ZvagCW1cq41L9k7eY2EI1bptYV0KVU4WP5OAVvEqQTKwfH?=
 =?us-ascii?Q?vUrih7LGE10bM1Zb92dN1Vf5Z6n2BN0pB4q22OqUe6NJSDzhxtX483Ueb3Fe?=
 =?us-ascii?Q?wvR9Utb9qxSQ7sV+KQ1toIz5uh1VjfWr7Zy4ZIbWXz4TSV5pwCyUi6pjSkG5?=
 =?us-ascii?Q?nI+zvViWAVE2diX2F1WnCyr3eyw3ig5Oo1xT88xzbfmv9vN+LVv9Sxy3mmGW?=
 =?us-ascii?Q?179C+ngCSxFX9iJ3LqF9Juw8Y9tLKe1GcseFNMufZzUTurVgQF0H+JbdhdoP?=
 =?us-ascii?Q?2maBQNKckQp+bk+Yisp1aXxvuRWbl+9fCP7BeWafyPAt7jmWYQI0iAe2AQH9?=
 =?us-ascii?Q?c2vT05mYQGcOhfEGQ7V0emz1L1J3oMwzOG0A7u0Rb8o6wT3ZpYE+nQprXBsu?=
 =?us-ascii?Q?QRl/jJDp2Dt+t3sXxUQadGtEj+fyubXKQ0V3tWpxKUNEXtetOEuAixPl/qfo?=
 =?us-ascii?Q?oBguyAuXNO2Ks+R5nwmq++HkggL96wKRxXH6lw/2+Yh+YUTYPLUDbq5yO5Qe?=
 =?us-ascii?Q?5l9VTej0T1vw9JHeNpDWCi5T1GHNZDTpuXMrquEMN+nyXK3PuTgtOdDgxRx9?=
 =?us-ascii?Q?dQgucl/H3ZkGfsbIjveqOjOc5dVLySwPWkBrbw+kOv/ggMMNx13eKz+CE5SZ?=
 =?us-ascii?Q?krlXl5tFf4o9cGf8hJYu/429Zu7qt8knnm/LpG0fwoOj2SyveNFnoP0v6eAZ?=
 =?us-ascii?Q?Uyk3zq9mKTnArLEdANzR8IFqNSOy1otdJFHd3ehG0USnkYp99tOJa3fCnHyK?=
 =?us-ascii?Q?7pjUM3EvxDqNZ4TDO99boedXxLs4A1o3iRnId0GLR5pJ0jFrSiPh27wUZANw?=
 =?us-ascii?Q?1Pn1Vd5YUaPaSv35s1VBEkuh3CGk1pyh3Glt1g3V8+xHoquBnzF49t8LtVxF?=
 =?us-ascii?Q?WIGRHL5H0HKY/9LNgvb3xO0lvToJl4lRCVAHnSOQzSiG7A9A1raIPxnxN0BX?=
 =?us-ascii?Q?R0mbu6vrzabi8HgLz2naPmXTiyGuVVjSdncwrMQn7UeG3QZxBKXm0X20Qfdr?=
 =?us-ascii?Q?jIOWIi/LfBmgAsnJeFzrfQgw1bLyU5c8eE9gHXoHQU509pfBlZkj1lnAwQ8h?=
 =?us-ascii?Q?NXsBhcGeF4Eayw4XL2fVJ0TMYYTXmhOnLMYvquoN2jvTAslT+Vk/xKrbIl3r?=
 =?us-ascii?Q?OOlbKziiCYgxiTFHX1TJKbr1UWqg9y4E5HSYs2Aj8wIDcKAydF+vyRkY5mDI?=
 =?us-ascii?Q?zi1XqOD9ah31A2W2/BooDf2++YQAFnYuJGgpTdSDtCekkW9J5bANJm6Hp0ns?=
 =?us-ascii?Q?ALmC1S+gAgEqAgjG+V7an9Yhlvuo1osf8xSRgV1X7f2hOfH1M2MOnGxnvL1D?=
 =?us-ascii?Q?NUS457+EI2gYsm7MdwWL3G871Ir1cA1vjsZEPMfNm3A5mKRE+gvNPhdoEjXj?=
 =?us-ascii?Q?tOA9RDdn3+EL2vu20vVWB6CoeOPUnbksv3l/PKGrasHdMP6xVp+mr5BpoAma?=
 =?us-ascii?Q?B0M70vJ3p3cukSHpfCWH8g/jHlvwlxS939EwmN31?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CY5PR11MB6365.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a80ec91b-89fa-43af-7212-08da8a4d39f6
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2022 06:02:31.5586
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: uNh263C2XAOY1xvf22YP8bhkmss06FtyoMoyTS19g8SHn9Ovjg1nNLFyJDGpC6pxv4meJRfKznRg43gUAiLe0g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1858
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tuesday, August 30, 2022 1:34 AM, Sean Christopherson wrote:
> 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))
>=20
> 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 tur=
n off it's
> own tracing.

Right, need to fix this one.

> This is effectively what I suggested[*], the main difference being that m=
y
> version adds dedicated enter/exit helpers so that perf can skip save/rest=
ore of
> the other MSRs. =20

What "other MSRs" were you referring to?
(I suppose you meant perf_event_disable needs to save more MSRs)

> It's easy to extend if perf needs to hand back an event to
> complete the "exit.
>=20
> 	bool guest_trace_enabled =3D vmx->pt_desc.guest.ctl &
> RTIT_CTL_TRACEEN;
>=20
> 	vmx->pt_desc.host_event =3D intel_pt_guest_enter(guest_trace_enabled);
>=20
>=20
> and then on exit
>=20
> 	bool guest_trace_enabled =3D vmx->pt_desc.guest.ctl &
> RTIT_CTL_TRACEEN;
>=20
> 	intel_pt_guest_exit(vmx->pt_desc.host_event, guest_trace_enabled);
>=20
> [*] https://lore.kernel.org/all/YwecducnM%2FU6tqJT@google.com

Yes, this can function. But I feel it a bit violates the general rule
that I got from previous experiences:
KVM should be a user of the perf subsystem, instead of implementing a secon=
dary
driver beyond perf's management.
Being a user of perf means everything possible should go through "perf even=
t",
which is the interface that perf exposes to users.