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 31656C77B73 for ; Tue, 6 Jun 2023 07:31:24 +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:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ODYK4AHgzhRv+S7ZenoYTD5IxSWGq9k/Vzi3fbtUZYw=; b=qydhFONYutPcaj hZ14zyPRCSM25afF9U0JeoUNF8DfhOwTpPzi/oAl3fTgOynocwi0I4jaFgTUDJhsdPFBg+J+g7cFP 3/Z7Smt3Bb3PBdPQRA8AYKgXZ9RRYnvR+E5zZ8mVfBRIftoHMxCf4lk7Sfbpj9XiRzNWRIwlB6rRu CAXLoNBKQLnTLhC2h8IR8ZSsMRlVoKMfF8d+bWdkdzCYD+3x4FbcpXRhGRWfX8om6iBUGanQtkbUg p6pxYsR53wEkMK3PcWPu7xU/iEpQAwsrIoaIWcCpbD7sWO3WMSqmSZwmUigb+UdAWz2RVX2L2RC1u KxVX0qFtQe0N5zd0XvlA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q6R9f-000XUn-1C; Tue, 06 Jun 2023 07:30:59 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q6R9c-000XUE-2k for linux-arm-kernel@lists.infradead.org; Tue, 06 Jun 2023 07:30:58 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 98C0162579; Tue, 6 Jun 2023 07:30:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0AF17C433EF; Tue, 6 Jun 2023 07:30:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686036655; bh=rO+/sQIGRRdehRdleQZnp1sl7uLZSD6lohy5Rq9t20I=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=B/dKhXQRDFrD2OgwZ7k3IZT1d5V46+HiNX2fAQcacX7rmpQpe4v/pE+oa2fc5oqEW n3/URPbh2dM3wLXHN+pqG4nKkhBFHB148Nb7tjzD+zqJbg9d2EuPewKMHIEZ1PxyAJ OmAQAUwVuEWfRxDAPdyXPOIwSPBJDoGcPk2UWhovFwX/bRocg8NnkafaQcjeRwpy0G wj42VXXYYpyRDrV6pdwUVT0b2zngPrXrwErCUMad0uXXcB7G+OCne6t+a2itezu987 SiJPFGYp33a5BURb8S/fRL2p2ZOxMZ/RFYH180I2XKLDE6v1ESG3nWKXoli7Itp9xV JFRX3ldxxazzg== Received: from 152.5.30.93.rev.sfr.net ([93.30.5.152] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1q6R9Y-0036r9-BZ; Tue, 06 Jun 2023 08:30:52 +0100 Date: Tue, 06 Jun 2023 08:30:50 +0100 Message-ID: <87r0qpnj2t.wl-maz@kernel.org> From: Marc Zyngier To: Eric Auger Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Alexandru Elisei , Andre Przywara , Chase Conklin , Christoffer Dall , Ganapatrao Kulkarni , Darren Hart , Jintack Lim , Russell King , Miguel Luis , James Morse , Suzuki K Poulose , Oliver Upton , Zenghui Yu Subject: Re: [PATCH v10 00/59] KVM: arm64: ARMv8.3/8.4 Nested Virtualization support In-Reply-To: <9cf2356b-f990-1cd2-c7e6-a984e9f604c6@redhat.com> References: <20230515173103.1017669-1-maz@kernel.org> <9cf2356b-f990-1cd2-c7e6-a984e9f604c6@redhat.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 93.30.5.152 X-SA-Exim-Rcpt-To: eauger@redhat.com, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, alexandru.elisei@arm.com, andre.przywara@arm.com, chase.conklin@arm.com, christoffer.dall@arm.com, gankulkarni@os.amperecomputing.com, darren@os.amperecomputing.com, jintack@cs.columbia.edu, rmk+kernel@armlinux.org.uk, miguel.luis@oracle.com, james.morse@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.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-20230606_003056_981344_6D032424 X-CRM114-Status: GOOD ( 33.07 ) 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 Hey Eric, On Mon, 05 Jun 2023 12:28:12 +0100, Eric Auger wrote: > > Hi Marc, > > On 5/15/23 19:30, Marc Zyngier wrote: > > This is the 4th drop of NV support on arm64 for this year. > > > > For the previous episodes, see [1]. > > > > What's changed: > > > > - New framework to track system register traps that are reinjected in > > guest EL2. It is expected to replace the discrete handling we have > > enjoyed so far, which didn't scale at all. This has already fixed a > > number of bugs that were hidden (a bunch of traps were never > > forwarded...). Still a work in progress, but this is going in the > > right direction. > > > > - Allow the L1 hypervisor to have a S2 that has an input larger than > > the L0 IPA space. This fixes a number of subtle issues, depending on > > how the initial guest was created. > > > > - Consequently, the patch series has gone longer again. Boo. But > > hopefully some of it is easier to review... > > > > [1] https://lore.kernel.org/r/20230405154008.3552854-1-maz@kernel.org > > > > Andre Przywara (1): > > KVM: arm64: nv: vgic: Allow userland to set VGIC maintenance IRQ > > I guess you have executed kselftests on L1 guests. Have all the tests > passed there? On my end it stalls in the KVM_RUN. No, I hardly run any kselftest, because they are just not designed to run at EL2 at all. There's some work to be done there, but I just don't have the bandwidth for that (hint, wink...) > > for instance > tools/testing/selftests/kvm/aarch64/aarch32_id_regs.c fails in > test_guest_raz(vcpu) on the KVM_RUN. Even with a basic > > static void guest_main(void) > { > GUEST_DONE(); > } My guess is that the test harness expects things to run at EL1. Depending on the value you get for HCR_EL2, you could get all sort of odd behaviours. Also, the harness configures EL1 only, which is unlikely to work at EL2. My conclusion is that "processor.c" needs to be taught about EL2, at the very least. > > I get > aarch32_id_regs-768 [002] ..... 410.544665: kvm_exit: IRQ: > HSR_EC: 0x0000 (UNKNOWN), PC: 0x0000000000401ec4 > aarch32_id_regs-768 [002] d.... 410.544666: kvm_entry: PC: > 0x0000000000401ec4 > aarch32_id_regs-768 [002] ..... 410.544675: kvm_exit: IRQ: > HSR_EC: 0x0000 (UNKNOWN), PC: 0x0000000000401ec4 > aarch32_id_regs-768 [002] d.... 410.544676: kvm_entry: PC: > 0x0000000000401ec4 > aarch32_id_regs-768 [002] ..... 410.544685: kvm_exit: IRQ: > HSR_EC: 0x0000 (UNKNOWN), PC: 0x0000000000401ec4 > > looping forever instead of > > aarch32_id_regs-1085576 [079] d..1. 1401295.068739: kvm_entry: PC: > 0x0000000000401ec4 > aarch32_id_regs-1085576 [079] ...1. 1401295.068745: kvm_exit: TRAP: > HSR_EC: 0x0020 (IABT_LOW), PC: 0x0000000000401ec4 > aarch32_id_regs-1085576 [079] d..1. 1401295.068790: kvm_entry: PC: > 0x0000000000401ec4 > aarch32_id_regs-1085576 [079] ...1. 1401295.068792: kvm_exit: TRAP: > HSR_EC: 0x0020 (IABT_LOW), PC: 0x0000000000401ec4 > aarch32_id_regs-1085576 [079] d..1. 1401295.068794: kvm_entry: PC: > 0x0000000000401ec4 > aarch32_id_regs-1085576 [079] ...1. 1401295.068795: kvm_exit: TRAP: > HSR_EC: 0x0020 (IABT_LOW), PC: 0x0000000000401ec4 > aarch32_id_regs-1085576 [079] d..1. 1401295.068797: kvm_entry: PC: > 0x0000000000401ec4 > ../.. > > Any idea or any known restriction wrt kselftests? See above. I'd love someone to actually start looking into it and devise a testing harness that would run both at EL{0,1,2} *at the same time* so that we can start exercising some of the trap behaviours that the architecture mandates. Also, Alexandru had a some KUT tests a few years ago, but I don't know what happened of them. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel