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 9B331C433EF for ; Sat, 4 Dec 2021 17:40:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344790AbhLDRnm (ORCPT ); Sat, 4 Dec 2021 12:43:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47514 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237061AbhLDRnl (ORCPT ); Sat, 4 Dec 2021 12:43:41 -0500 Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0F59FC0613F8 for ; Sat, 4 Dec 2021 09:40:16 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id p18so4274194plf.13 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=gBOai/Cbt17yKH1jxepEjNQJoBmo4Lt5f/tSo3MSwP/jAaCkiX74mP5qczLNhJIjo/ KRAfF0Fx01iQq/4VYiYdfoKdOZIsagbJykQhFMlrgLMkd9Lxk6m4kaUmbPv5mqj319I/ 1s7CH2xv/jZraLVJQ+Q59vW+LxQW+T4iPB/bRNsdeyYsLkjeiZSn2PAlXh51cv9VWT+u HFGtduZ4uGB7Qfmdfm9a7AaKACaYFWP8HCXgilwBmD8F7KHRx1DEJHTa/fPTzu+3crY5 Dx67MDC1YCrM3IHFebN2M21apQk1Ay5JZyOmLrbwEnZHQSRZsMLpQPQv2tLkXn2Jo0Tn nd9w== X-Gm-Message-State: AOAM5308dvZeuCjbu3qll3VylZB8gexuIRpOPWVYb3q19MJkMaHYZJoK XW0aWqMCzVJZpU8UfCXdsp+8SO2wuweEMDWo4L+wrg== 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.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 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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A50BC433F5 for ; Sat, 4 Dec 2021 17:40:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 043AB4086F; Sat, 4 Dec 2021 12:40:21 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, body has been altered) header.i=@google.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVjBEhaE0Aky; Sat, 4 Dec 2021 12:40:19 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 47E6649DE3; Sat, 4 Dec 2021 12:40:19 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id C64D34086F for ; Sat, 4 Dec 2021 12:40:17 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piKIBDk8FU5I for ; Sat, 4 Dec 2021 12:40:16 -0500 (EST) Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 67D62407F1 for ; Sat, 4 Dec 2021 12:40:16 -0500 (EST) Received: by mail-pl1-f182.google.com with SMTP id k4so4292212plx.8 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=A9kCV6dfF822vUA/6p3ShWdrbEReatuFo3I683/j/2GpDUoZ7Bf8GPWb0Pa96ylRE/ cFTo2WdzXjXZimMnPH6FtUtiFMOyZTwh78JOBSPWoT9UV1BzgrFmEQTpRG3W9g4Kiut/ tURQVnL7babgfOlaRQ8F8HG7sUX9yrBR8TNvHWN8EVDit4EFIFFy+J9u0zagNebERBLs kg/kVW4t+8Sv3raxJOBP/7fxW1hHTFIzFqc0TTJNh1q1dgfPMhPC195yDLXDwgSBmozw ePQoBZ5RkzHV851PRaTAs9iopYVO6o0Jd/1UrU+tzrwFZIyUmPpZ1JYkZUQB65Dg/J5Y m+bQ== X-Gm-Message-State: AOAM533VvHzwp0Gcejj8ypNO/44PFD81Wf5NXY+QbUidoiWBr/1Z1see zAPjhQXd0ESokrpo3B1HstAHwnGpjPQzpNGGpczQTw== 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-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu 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 _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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