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 X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6EC5AC433E0 for ; Mon, 4 Jan 2021 16:27:26 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id D119322473 for ; Mon, 4 Jan 2021 16:27:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D119322473 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 5AA0B4B2D5; Mon, 4 Jan 2021 11:27:25 -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 7RB6+GjVMWzR; Mon, 4 Jan 2021 11:27:24 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 3C6AC4B2D4; Mon, 4 Jan 2021 11:27:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id C012F4B2D4 for ; Mon, 4 Jan 2021 11:27:23 -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 1hwgN32QrbxK for ; Mon, 4 Jan 2021 11:27:22 -0500 (EST) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 887944B1BF for ; Mon, 4 Jan 2021 11:27:22 -0500 (EST) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 637C22245C; Mon, 4 Jan 2021 16:27:21 +0000 (UTC) Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1kwShT-005GQQ-A0; Mon, 04 Jan 2021 16:27:19 +0000 MIME-Version: 1.0 Date: Mon, 04 Jan 2021 16:27:19 +0000 From: Marc Zyngier To: Qian Cai Subject: Re: [PATCH] KVM: arm64: Don't access PMCR_EL0 when no PMU is available In-Reply-To: References: <20201210083059.1277162-1-maz@kernel.org> <703e1b5f2db1631e8f9c55619909fe66eb069f25.camel@redhat.com> <579c839a0016107af66e704f147f9814@kernel.org> User-Agent: Roundcube Webmail/1.4.9 Message-ID: X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: qcai@redhat.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kernel-team@android.com, sfr@canb.auug.org.au, linux-next@vger.kernel.org, alexandru.elisei@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: Stephen Rothwell , Linux Next Mailing List , kernel-team@android.com, 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On 2021-01-04 16:22, Qian Cai wrote: > On Mon, 2021-01-04 at 16:08 +0000, Marc Zyngier wrote: >> On 2021-01-04 15:47, Qian Cai wrote: >> > On Thu, 2020-12-10 at 08:30 +0000, Marc Zyngier wrote: >> > > We reset the guest's view of PMCR_EL0 unconditionally, based on >> > > the host's view of this register. It is however legal for an >> > > imnplementation not to provide any PMU, resulting in an UNDEF. >> > > >> > > The obvious fix is to skip the reset of this shadow register >> > > when no PMU is available, sidestepping the issue entirely. >> > > If no PMU is available, the guest is not able to request >> > > a virtual PMU anyway, so not doing nothing is the right thing >> > > to do! >> > > >> > > It is unlikely that this bug can hit any HW implementation >> > > though, as they all provide a PMU. It has been found using nested >> > > virt with the host KVM not implementing the PMU itself. >> > > >> > > Fixes: ab9468340d2bc ("arm64: KVM: Add access handler for PMCR >> > > register") >> > > Signed-off-by: Marc Zyngier >> > >> > Reverting this commit on the top of today's linux-next fixed a qemu-kvm >> > coredump >> > issue on TX2 while starting a guest. >> > >> > - host kernel .config: >> > https://cailca.coding.net/public/linux/mm/git/files/master/arm64.config >> > >> > # /usr/libexec/qemu-kvm -name ubuntu-20.04-server-cloudimg -cpu host >> > -smp 2 -m 2g >> > -drive >> > if=none,format=qcow2,file=./ubuntu-20.04-server-cloudimg.qcow2,id=hd >> > -device virtio-scsi -device scsi-hd,drive=hd -cdrom >> > ./ubuntu-20.04-server-cloudimg.iso >> > -bios /usr/share/AAVMF/AAVMF_CODE.fd -M gic-version=host -nographic >> > -nic user,model=virtio,hostfwd=tcp::2222-:22 >> > >> > qemu-kvm: /builddir/build/BUILD/qemu-4.2.0/target/arm/helper.c:1812: >> > pmevcntr_rawwrite: Assertion `counter < pmu_num_counters(env)' failed. >> >> You don't have KVM_ARM_PMU selected in your config, so QEMU cannot >> access the PMU registers, and no counters are exposed. > > Well, isn't it the rule that don't break the userspace? qemu works fine > with > KVM_ARM_PMU=n until this commit. No, it doesn't "work fine". It gets random data that potentially makes no sense, depending on the HW this runs on. Now, userspace tells you that your kernel is misconfigured. I see it as an improvement. M. -- Jazz is not dead. It just smells funny... _______________________________________________ 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 X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3BDE1C433DB for ; Mon, 4 Jan 2021 16:28:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E224422473 for ; Mon, 4 Jan 2021 16:28:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727770AbhADQ2C (ORCPT ); Mon, 4 Jan 2021 11:28:02 -0500 Received: from mail.kernel.org ([198.145.29.99]:50656 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727749AbhADQ2C (ORCPT ); Mon, 4 Jan 2021 11:28:02 -0500 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 637C22245C; Mon, 4 Jan 2021 16:27:21 +0000 (UTC) Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1kwShT-005GQQ-A0; Mon, 04 Jan 2021 16:27:19 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 04 Jan 2021 16:27:19 +0000 From: Marc Zyngier To: Qian Cai Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kernel-team@android.com, Stephen Rothwell , Linux Next Mailing List , Alexandru Elisei Subject: Re: [PATCH] KVM: arm64: Don't access PMCR_EL0 when no PMU is available In-Reply-To: References: <20201210083059.1277162-1-maz@kernel.org> <703e1b5f2db1631e8f9c55619909fe66eb069f25.camel@redhat.com> <579c839a0016107af66e704f147f9814@kernel.org> User-Agent: Roundcube Webmail/1.4.9 Message-ID: X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: qcai@redhat.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kernel-team@android.com, sfr@canb.auug.org.au, linux-next@vger.kernel.org, alexandru.elisei@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-next@vger.kernel.org On 2021-01-04 16:22, Qian Cai wrote: > On Mon, 2021-01-04 at 16:08 +0000, Marc Zyngier wrote: >> On 2021-01-04 15:47, Qian Cai wrote: >> > On Thu, 2020-12-10 at 08:30 +0000, Marc Zyngier wrote: >> > > We reset the guest's view of PMCR_EL0 unconditionally, based on >> > > the host's view of this register. It is however legal for an >> > > imnplementation not to provide any PMU, resulting in an UNDEF. >> > > >> > > The obvious fix is to skip the reset of this shadow register >> > > when no PMU is available, sidestepping the issue entirely. >> > > If no PMU is available, the guest is not able to request >> > > a virtual PMU anyway, so not doing nothing is the right thing >> > > to do! >> > > >> > > It is unlikely that this bug can hit any HW implementation >> > > though, as they all provide a PMU. It has been found using nested >> > > virt with the host KVM not implementing the PMU itself. >> > > >> > > Fixes: ab9468340d2bc ("arm64: KVM: Add access handler for PMCR >> > > register") >> > > Signed-off-by: Marc Zyngier >> > >> > Reverting this commit on the top of today's linux-next fixed a qemu-kvm >> > coredump >> > issue on TX2 while starting a guest. >> > >> > - host kernel .config: >> > https://cailca.coding.net/public/linux/mm/git/files/master/arm64.config >> > >> > # /usr/libexec/qemu-kvm -name ubuntu-20.04-server-cloudimg -cpu host >> > -smp 2 -m 2g >> > -drive >> > if=none,format=qcow2,file=./ubuntu-20.04-server-cloudimg.qcow2,id=hd >> > -device virtio-scsi -device scsi-hd,drive=hd -cdrom >> > ./ubuntu-20.04-server-cloudimg.iso >> > -bios /usr/share/AAVMF/AAVMF_CODE.fd -M gic-version=host -nographic >> > -nic user,model=virtio,hostfwd=tcp::2222-:22 >> > >> > qemu-kvm: /builddir/build/BUILD/qemu-4.2.0/target/arm/helper.c:1812: >> > pmevcntr_rawwrite: Assertion `counter < pmu_num_counters(env)' failed. >> >> You don't have KVM_ARM_PMU selected in your config, so QEMU cannot >> access the PMU registers, and no counters are exposed. > > Well, isn't it the rule that don't break the userspace? qemu works fine > with > KVM_ARM_PMU=n until this commit. No, it doesn't "work fine". It gets random data that potentially makes no sense, depending on the HW this runs on. Now, userspace tells you that your kernel is misconfigured. I see it as an improvement. M. -- Jazz is not dead. It just smells funny... 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 X-Spam-Level: X-Spam-Status: No, score=-9.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60B9FC433DB for ; Mon, 4 Jan 2021 16:28:43 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 056A32245C for ; Mon, 4 Jan 2021 16:28:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 056A32245C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=fAFtgPzURz65IWHG0dZ87ju+m+Lfi1j4E2WEWbhV6jo=; b=ki/1kF9VlnQ7qXwq4LecoxmpU Jtxj9XfeDkIvgIAcQS7zxtNhi4Ky+nyGLOpoqnJU3VIRGDaj2n/If58a0jslVtkMmtxRk9gGyL0op BBZvkvmK4HYX/BwgVQU3qcwurzYvzt/R7DxG6mzYDQtGkOmTO+IolR6WwVNPDLd1tTW7+UESGTic6 LoHtkUbKhpIjzpTw2/RAAlc49gYxgGf8h+mTnGWdQQMH0Z2N4NJXHHSFXwHHfpiYIiWX7VhGAFKiy S/gAKC7aCS90R5r2WERj7zI68gzAGXt+L+ohW283hHP81yW+gy5Qm5xKdkuZGNsBGsH/LEvix2p0b RAz3Q2s8A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kwShZ-0000pq-Jy; Mon, 04 Jan 2021 16:27:25 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kwShW-0000pJ-E6 for linux-arm-kernel@lists.infradead.org; Mon, 04 Jan 2021 16:27:23 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 637C22245C; Mon, 4 Jan 2021 16:27:21 +0000 (UTC) Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1kwShT-005GQQ-A0; Mon, 04 Jan 2021 16:27:19 +0000 MIME-Version: 1.0 Date: Mon, 04 Jan 2021 16:27:19 +0000 From: Marc Zyngier To: Qian Cai Subject: Re: [PATCH] KVM: arm64: Don't access PMCR_EL0 when no PMU is available In-Reply-To: References: <20201210083059.1277162-1-maz@kernel.org> <703e1b5f2db1631e8f9c55619909fe66eb069f25.camel@redhat.com> <579c839a0016107af66e704f147f9814@kernel.org> User-Agent: Roundcube Webmail/1.4.9 Message-ID: X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: qcai@redhat.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kernel-team@android.com, sfr@canb.auug.org.au, linux-next@vger.kernel.org, alexandru.elisei@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210104_112722_627185_710F8397 X-CRM114-Status: GOOD ( 23.14 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Stephen Rothwell , Alexandru Elisei , Linux Next Mailing List , kernel-team@android.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2021-01-04 16:22, Qian Cai wrote: > On Mon, 2021-01-04 at 16:08 +0000, Marc Zyngier wrote: >> On 2021-01-04 15:47, Qian Cai wrote: >> > On Thu, 2020-12-10 at 08:30 +0000, Marc Zyngier wrote: >> > > We reset the guest's view of PMCR_EL0 unconditionally, based on >> > > the host's view of this register. It is however legal for an >> > > imnplementation not to provide any PMU, resulting in an UNDEF. >> > > >> > > The obvious fix is to skip the reset of this shadow register >> > > when no PMU is available, sidestepping the issue entirely. >> > > If no PMU is available, the guest is not able to request >> > > a virtual PMU anyway, so not doing nothing is the right thing >> > > to do! >> > > >> > > It is unlikely that this bug can hit any HW implementation >> > > though, as they all provide a PMU. It has been found using nested >> > > virt with the host KVM not implementing the PMU itself. >> > > >> > > Fixes: ab9468340d2bc ("arm64: KVM: Add access handler for PMCR >> > > register") >> > > Signed-off-by: Marc Zyngier >> > >> > Reverting this commit on the top of today's linux-next fixed a qemu-kvm >> > coredump >> > issue on TX2 while starting a guest. >> > >> > - host kernel .config: >> > https://cailca.coding.net/public/linux/mm/git/files/master/arm64.config >> > >> > # /usr/libexec/qemu-kvm -name ubuntu-20.04-server-cloudimg -cpu host >> > -smp 2 -m 2g >> > -drive >> > if=none,format=qcow2,file=./ubuntu-20.04-server-cloudimg.qcow2,id=hd >> > -device virtio-scsi -device scsi-hd,drive=hd -cdrom >> > ./ubuntu-20.04-server-cloudimg.iso >> > -bios /usr/share/AAVMF/AAVMF_CODE.fd -M gic-version=host -nographic >> > -nic user,model=virtio,hostfwd=tcp::2222-:22 >> > >> > qemu-kvm: /builddir/build/BUILD/qemu-4.2.0/target/arm/helper.c:1812: >> > pmevcntr_rawwrite: Assertion `counter < pmu_num_counters(env)' failed. >> >> You don't have KVM_ARM_PMU selected in your config, so QEMU cannot >> access the PMU registers, and no counters are exposed. > > Well, isn't it the rule that don't break the userspace? qemu works fine > with > KVM_ARM_PMU=n until this commit. No, it doesn't "work fine". It gets random data that potentially makes no sense, depending on the HW this runs on. Now, userspace tells you that your kernel is misconfigured. I see it as an improvement. M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel