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 2826AE810D0 for ; Wed, 27 Sep 2023 11:33:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231444AbjI0Ldz (ORCPT ); Wed, 27 Sep 2023 07:33:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40214 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231391AbjI0Ldl (ORCPT ); Wed, 27 Sep 2023 07:33:41 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5E23D199; Wed, 27 Sep 2023 04:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=ELXRd2+VoCH1I99QYOA/3TEPv4nC2Y881FhqGK/auxc=; b=YWKDH/YiyjT5Dq/JDiSk6c7qUD c5/JkA5GFfOxYnB/+9sbB9SGxVf8M24jp0utbGyNIKU852uCoZS5CqxpPznaCBrWe1luDFC68fBlw RJQ4M2K6sG6UhKeGNtNRKdMVH/5DuYyGcK4TxtDcLP4NwAig5vy69nnNMWbIVt/PtDs8souYj8kwD fXDliBfzL66rBFFMwPDc6/lw7zhkrL/X604/DSIW3Oz3cXE5vjWd0XknfxKYTcDx/Gx8HwKivqpCY Rm2TISRgyw6nOXPc0Tc8ePBGGsGUHUkeO47+sr0R2E5ljQgWgLG+0e7XhbdjEZqKAIC1u57yzITAv 6Ch4WpgA==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1qlSn3-00DcAy-8o; Wed, 27 Sep 2023 11:33:13 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id E8AF3300473; Wed, 27 Sep 2023 13:33:12 +0200 (CEST) Date: Wed, 27 Sep 2023 13:33:12 +0200 From: Peter Zijlstra To: Dapeng Mi Cc: Sean Christopherson , Paolo Bonzini , Arnaldo Carvalho de Melo , Kan Liang , Like Xu , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Ian Rogers , Adrian Hunter , kvm@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, Zhenyu Wang , Zhang Xiong , Lv Zhiyuan , Yang Weijiang , Dapeng Mi Subject: Re: [Patch v4 07/13] perf/x86: Add constraint for guest perf metrics event Message-ID: <20230927113312.GD21810@noisy.programming.kicks-ass.net> References: <20230927033124.1226509-1-dapeng1.mi@linux.intel.com> <20230927033124.1226509-8-dapeng1.mi@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230927033124.1226509-8-dapeng1.mi@linux.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 27, 2023 at 11:31:18AM +0800, Dapeng Mi wrote: > When guest wants to use PERF_METRICS MSR, a virtual metrics event needs > to be created in the perf subsystem so that the guest can have exclusive > ownership of the PERF_METRICS MSR. Urgh, can someone please remind me how all that is supposed to work again? The guest is just a task that wants the event. If the host creates a CPU event, then that gets scheduled with higher priority and the task looses out, no joy. So you cannot guarantee the guest gets anything. That is, I remember we've had this exact problem before, but I keep forgetting how this all is supposed to work. I don't use this virt stuff (and every time I try qemu arguments defeat me and I give up in disgust).