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 B6F70C19F2A for ; Thu, 4 Aug 2022 15:00:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240131AbiHDPA4 (ORCPT ); Thu, 4 Aug 2022 11:00:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41190 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240153AbiHDPAv (ORCPT ); Thu, 4 Aug 2022 11:00:51 -0400 Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 676F013F66 for ; Thu, 4 Aug 2022 08:00:50 -0700 (PDT) Received: by mail-pf1-x42c.google.com with SMTP id w185so19591765pfb.4 for ; Thu, 04 Aug 2022 08:00:50 -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=IaifTpn3u0w2qUkig48qynKFfInn0OoAePTEgfMQ/6g=; b=SM4HtroITzHOZUFHTx7wGP7tvdu9IAxGSxtCMAsBe810xu9aIob9MCZbOolfYzn2+e j79pj5EZWJJzVBm+DlQ9qL0YGGyMyf/egYOSXlw8RgRiClXjQpthTrp7Iqh3PIPjnPAn 8+TJD8GinwO57p/omdUnuI5NwqNeM/WSRUkLJT77l1kK5Z4bFz3EuPcZDKrCtkP+ptrr 0n/tLCQMaprvpWJ4hh+JWoWexfkLJE+kbl41zeroCm6WyfmY97oCLde4x/mAI5hEbBin fSB7HHpNIuAsqyLbyIMYwB3mCYCMkcOCi78C1cbpMRas/0ldqGJvXkvK2lzByC0iONsi oEMA== 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=IaifTpn3u0w2qUkig48qynKFfInn0OoAePTEgfMQ/6g=; b=mlu8AnFvFVA9Gwv6E4SNzV9WXSyAJMjwjT5FXFhQXxifRT+5t2M0Qh+6t7mcUprhVX 05NIGalhQo7P2pihjkaHWtGK6CFd11oPSIgLWJkSEa6fUOqZbqKtie+tnfc+56zT8n5g Kj6T6xEBAxEuhoB/v9E1sQ+JQmKqdv+ehnvlzK7MFLN4KycyBKW35zpcPENS5lwclpf7 CRg6F6zaj9+KBxPh5O3t8DwaEm4cJU5KxtD7Y3G4P6m/xWgT6QHw/CTnWdfC3J4Jw7yE GEipKmmN9JaEMmCrcUXvdCGE3JTkn4COZI/cAwEZ8Rp3Vs+OPD7iL8DM7JyZ4Mo83BRI hfGw== X-Gm-Message-State: ACgBeo08wlc79qEUKo5M65KaiTTiq8oRp+AshtfLvDOqpwY5dXoUfsrD 5Nq9TZX5qoThzuiGZHyDLadN/w== X-Google-Smtp-Source: AA6agR6vOOf5eInTDw94W1UE+cE40wpAwMxYjG3kliNFyyKOGQTat2W+Q3wfOpjiZ2CFqYuVxfrSRg== X-Received: by 2002:aa7:919a:0:b0:52a:eeef:3e65 with SMTP id x26-20020aa7919a000000b0052aeeef3e65mr2112688pfa.15.1659625249718; Thu, 04 Aug 2022 08:00:49 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id e6-20020a170902784600b0016357fd0fd1sm1119297pln.69.2022.08.04.08.00.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Aug 2022 08:00:49 -0700 (PDT) Date: Thu, 4 Aug 2022 15:00:45 +0000 From: Sean Christopherson To: Like Xu Cc: Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Paolo Bonzini , Peter Zijlstra , Arnaldo Carvalho de Melo , Ingo Molnar Subject: Re: [PATCH v2 7/7] KVM: VMX: Simplify capability check when handling PERF_CAPABILITIES write Message-ID: References: <20220803192658.860033-1-seanjc@google.com> <20220803192658.860033-8-seanjc@google.com> <41e0b2a0-c53d-870f-d619-4008eb222d42@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41e0b2a0-c53d-870f-d619-4008eb222d42@gmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-perf-users@vger.kernel.org On Thu, Aug 04, 2022, Like Xu wrote: > On 4/8/2022 3:26 am, Sean Christopherson wrote: > > Explicitly check for the absence of host support for LBRs or PEBS when > > userspace attempts to enable said features by writing PERF_CAPABILITIES. > > Comparing host support against the incoming value is unnecessary and > > weird since the checks are buried inside an if-statement that verifies > > userspace wants to enable the feature. > > If you mean this part in the KVM: > > case MSR_IA32_PERF_CAPABILITIES: { > ... > if (data & ~msr_ent.data) > return 1; > ... > > then this patch brings a flaw, for example: > > a user space can successfully set 0x1 on a host that reports a value of 0x5, > which should not happen since the semantics of 0x1 and 0x5 for LBR_FMT > may be completely different from the guest LBR driver's perspective. /facepalm I keep forgetting the caps need to match the host exactly. Thanks!