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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8E9C3C433EF for ; Sat, 4 Dec 2021 17:41:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=5H5AWQBH5izh4uwB0SWQBYVCf+fHOFAwOmg7Kp+L4V8=; b=uOki2GY2gvXGUC 4NDf68WOg/nlRto0h3SRYpUjRPMV/yDpMVD38f0COfVVNsZOCnqTKn3nwllFZ+ZVZhVkOVylc9taM 6EMquWlW/3dzGVDB2hN8+wLPuJPISjQ8fTnvSLEFG7Wzh7/Fu++3KdTKbAaim2XghblbTzU5qyEYG VBOPrxa/X9rnIN/UQESFY2FCe1IKwCNyzIc98WkMGBQvQrHV2N0IX90XNqUJTthFzbvQ7YU5OlcrT A3CBxnNGnGzKkGNQnJn5owrJ2ocIXA9lovVOsh9p00F85Q1TV2aYg/dSTHndbKPavm3xbDuh4kHmF rl3B9ztKshjnA2oN3bAg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mtZ1K-000bZT-QG; Sat, 04 Dec 2021 17:40:22 +0000 Received: from mail-pl1-x62e.google.com ([2607:f8b0:4864:20::62e]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mtZ1G-000bY4-Dc for linux-arm-kernel@lists.infradead.org; Sat, 04 Dec 2021 17:40:20 +0000 Received: by mail-pl1-x62e.google.com with SMTP id b13so4313933plg.2 for ; Sat, 04 Dec 2021 09:40:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nAML//PJUUZoaUHQ1962i3snmMVvfIzEeG+c390MWrw=; b=YKzSumkwYSJVf9OzGVbWTtFymqaakJiJZkTQrt5sEWnXwiD7jim8POQZHJVunxLPb9 A53M8zWKaIEoibqBNjdrElSIDwbQ6V6pjywTVBQrFvMRHmeYkaiMRSrIX8jaVS2m8vkG rTovtpjuBwoC2SmW09dCrCHM/idCkyhFqKQW/T21PHHnpEB/H4B55Nuu1mQSBhQI9C8i VWw6oHjXgyuew6BLR5lHex5arHglka3fT5Ic1bJczb8nefaJrWUFQv4WV/JGn7WNz/+b hUNs2fzpbTmYQWcGyNAy+Rez+8fhYeqWiAU33QJGb0fqyPIj02ypbxDHDX1MZihHa2e8 54Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nAML//PJUUZoaUHQ1962i3snmMVvfIzEeG+c390MWrw=; b=cZdUBwffQdaTVw0Rwpse3VI2Xxy03mRowXGPCxARTfI3pAO5II/t98zRgPgJ4bFgcf 4V4tIR7WVasy3TotNnT+v5dDS6reacStU5mNh4/HVd8Xnxye3DNDh7lj58SS9UGOxEDd DELX5zRh7wd8wdOMZpNdgsVg537Y/1G+w+sMvQ8M5cIqyzPUOSSsMniBkQmANTh4ImMr RL2ViFkpUlHc/odoFZkRNseFmsKhpbrN6ow6K2rnXVzdnUITaJflGgQ46ngUzH2TgUpq DUGzh+fTKGnXpZ9P4vtMQ3hSox4odV8XIeXA3HQtdFX757Re/6yowNrlhEf/YjKDbnms Lx/g== X-Gm-Message-State: AOAM532kWBzu6/79xw1SaTz732iwZiLnYvDuTzDzcgcSwJyxFvJ0tv5x pErFroSULSKuzW+1j+PuwXH6mM4GOCXZ+P4T1joj1RSuchvSAQ== X-Google-Smtp-Source: ABdhPJySXkYEx4y6c/qY5zQLq1N0SKWwbAw86C1KE+EUAdCgGivHvW6bJ2rH009gUore2EP+VCxR+ox75gwVxHMMhAA= X-Received: by 2002:a17:90b:380d:: with SMTP id mq13mr23805796pjb.110.1638639615375; Sat, 04 Dec 2021 09:40:15 -0800 (PST) MIME-Version: 1.0 References: <20211117064359.2362060-1-reijiw@google.com> <20211117064359.2362060-10-reijiw@google.com> <5bd01c9c-6ac8-4034-6f49-be636a3b287c@redhat.com> <2ed3072b-f83d-1b17-0949-ca38267ba94e@redhat.com> In-Reply-To: <2ed3072b-f83d-1b17-0949-ca38267ba94e@redhat.com> From: Reiji Watanabe Date: Sat, 4 Dec 2021 09:39:59 -0800 Message-ID: Subject: Re: [RFC PATCH v3 09/29] KVM: arm64: Hide IMPLEMENTATION DEFINED PMU support for the guest To: Eric Auger Cc: kvm@vger.kernel.org, Marc Zyngier , Peter Shier , Paolo Bonzini , Will Deacon , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211204_094018_490799_1A2AD7F2 X-CRM114-Status: GOOD ( 31.44 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Eric, On Sat, Dec 4, 2021 at 6:14 AM Eric Auger wrote: > > Hi Reiji, > > On 12/4/21 2:04 AM, Reiji Watanabe wrote: > > Hi Eric, > > > > On Thu, Dec 2, 2021 at 2:57 AM Eric Auger wrote: > >> > >> Hi Reiji, > >> > >> On 11/30/21 6:32 AM, Reiji Watanabe wrote: > >>> Hi Eric, > >>> > >>> On Thu, Nov 25, 2021 at 12:30 PM Eric Auger wrote: > >>>> > >>>> Hi Reiji, > >>>> > >>>> On 11/17/21 7:43 AM, Reiji Watanabe wrote: > >>>>> When ID_AA64DFR0_EL1.PMUVER or ID_DFR0_EL1.PERFMON is 0xf, which > >>>>> means IMPLEMENTATION DEFINED PMU supported, KVM unconditionally > >>>>> expose the value for the guest as it is. Since KVM doesn't support > >>>>> IMPLEMENTATION DEFINED PMU for the guest, in that case KVM should > >>>>> exopse 0x0 (PMU is not implemented) instead. > >>>> s/exopse/expose > >>>>> > >>>>> Change cpuid_feature_cap_perfmon_field() to update the field value > >>>>> to 0x0 when it is 0xf. > >>>> is it wrong to expose the guest with a Perfmon value of 0xF? Then the > >>>> guest should not use it as a PMUv3? > >>> > >>>> is it wrong to expose the guest with a Perfmon value of 0xF? Then the > >>>> guest should not use it as a PMUv3? > >>> > >>> For the value 0xf in ID_AA64DFR0_EL1.PMUVER and ID_DFR0_EL1.PERFMON, > >>> Arm ARM says: > >>> "IMPLEMENTATION DEFINED form of performance monitors supported, > >>> PMUv3 not supported." > >>> > >>> Since the PMU that KVM supports for guests is PMUv3, 0xf shouldn't > >>> be exposed to guests (And this patch series doesn't allow userspace > >>> to set the fields to 0xf for guests). > >> What I don't get is why this isn't detected before (in kvm_reset_vcpu). > >> if the VCPU was initialized with KVM_ARM_VCPU_PMU_V3 can we honor this > >> init request if the host pmu is implementation defined? > > > > KVM_ARM_VCPU_INIT with KVM_ARM_VCPU_PMU_V3 will fail in > > kvm_reset_vcpu() if the host PMU is implementation defined. > > OK. This was not obvsious to me. > > if (kvm_vcpu_has_pmu(vcpu) && !kvm_arm_support_pmu_v3()) { > ret = -EINVAL; > goto out; > } > > kvm_perf_init > + if (perf_num_counters() > 0) > + static_branch_enable(&kvm_arm_pmu_available); > > But I believe you ;-), sorry for the noise Thank you for the review ! I didn't find the code above in v5.16-rc3, which is the base code of this series. So, I'm not sure where the code came from (any kvmarm repository branch ??). What I see in v5.16-rc3 is: ---- int kvm_perf_init(void) { return perf_register_guest_info_callbacks(&kvm_guest_cbs); } void kvm_host_pmu_init(struct arm_pmu *pmu) { if (pmu->pmuver != 0 && pmu->pmuver != ID_AA64DFR0_PMUVER_IMP_DEF && !kvm_arm_support_pmu_v3() && !is_protected_kvm_enabled()) static_branch_enable(&kvm_arm_pmu_available); } ---- And I don't find any other code that enables kvm_arm_pmu_available. Looking at the KVM's PMUV3 support code for guests in v5.16-rc3, if KVM allows userspace to configure KVM_ARM_VCPU_PMU_V3 even with ID_AA64DFR0_PMUVER_IMP_DEF on the host (, which I don't think it does), I think we should fix that to not allow that. (I'm not sure how KVM's PMUV3 support code is implemented in the code that you are looking at though) Thanks, Reiji _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel