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 B663DCE8D47 for ; Fri, 14 Nov 2025 15:42:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=+od2OKRi/m9M/nOf4TXwToQ8FWncMU0TTof0NZl1NvI=; b=oAjgRgbu5nntQYh0kdYIhdhFxZ Bcok1zsNLZRlUP0X4PpaDuwmJ5fCsrksJ2fug/FWRT4W6JLr+/s910kptFxr0fL7JajjIWHfeWxMH 0ceS5Kh39Dmk9Zx7/TXk3Ch7KCyIhjr6TBCPaXBIrB2ajcpCnH0ihnOGMvCY8zJlf4xlxxB+sFIZG KI2pf7CeEeDIn0gRBRWrd4Z1ewPw0EpBYZQkhTnWE+kn3jMpWTxnZ6yJrfPcfRLSWDAlQvQoQlnm6 3c2xI/LOKggQ7z651AIyfdC/9uVaiJ9WN6vmM70ekOhF2gG5f2Bq4ZsHs2vxYcE+1KangxaWewH+H pY82eDpQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vJvwY-0000000CbIN-2b3S; Fri, 14 Nov 2025 15:42:34 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vJvwX-0000000CbHr-40Do for linux-arm-kernel@lists.infradead.org; Fri, 14 Nov 2025 15:42:34 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 5EC7A60179; Fri, 14 Nov 2025 15:42:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 26FE4C4CEF5; Fri, 14 Nov 2025 15:42:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763134953; bh=/YV/NDL8G+NnwKpf6JduT0mxliwb3hgm6r5W350c8dc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=V6MXteKI2Hzpfl6Dxbuj+zMhLd47lr1GFmk39zEhPt/TFWRu+B0mi5lFA+flFmLjp qHBoGR34u1qYDMrbVeCGCooDE3pB4STyChmI+l0gAq9hMSg2Fw0nmtNX1Ycgb4vMhv FzX1iB/1EjdqE1Qd0Lep6nUEsrJrTrr/YT4150tzZ/35I/NlnPEIzCUpjMsmJmWBH1 EmleZd1EEFW9w5Ly0GnXYMtyfj/j9391L6cFFOv5NSbybSbgtc/oV+LD+ezk0f9NRV cKXLN0ei/yxh19szflJbY8b1uhkWbI5DzT5lnjFtgRaQxL5sQU0SM9sQmwpLto0kAj My42yp/sR2igw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vJvwU-00000005G01-2hlJ; Fri, 14 Nov 2025 15:42:30 +0000 Date: Fri, 14 Nov 2025 15:42:30 +0000 Message-ID: <86bjl4tyc9.wl-maz@kernel.org> From: Marc Zyngier To: Maximilian Dittgen Cc: , , , , , , , , Subject: Re: [PATCH] KVM: selftests: Add SYNC after guest ITS setup in vgic_lpi_stress In-Reply-To: <20251114143902.30435-1-mdittgen@amazon.de> References: <20251114143902.30435-1-mdittgen@amazon.de> 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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: mdittgen@amazon.de, oliver.upton@linux.dev, pbonzini@redhat.com, shuah@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kselftest@vger.kernel.org, kvm@vger.kernel.org, lilitj@amazon.de, nh-open-source@amazon.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 14 Nov 2025 14:39:02 +0000, Maximilian Dittgen wrote: > > vgic_lpi_stress sends MAPTI and MAPC commands during guest GIC > setup to map interrupt events to ITT entries and collection IDs > to redistributors, respectively. > > Theoretically, we have no guarantee that the ITS will > finish handling these mapping commands before the selftest > calls KVM_SIGNAL_MSI to inject LPIs to the guest. If LPIs > are injected before ITS mapping completes, the ITS cannot > properly pass the interrupt on to the redistributor. > > In practice, KVM processes ITS commands synchronously, so > SYNC calls are functionally unnecessary and ignored in > vgic_its_handle_command(). > > However, selftests should test based on ARM specification and > be blind to KVM-specific implementation optimizations. Thus, That's hardly an optimisation. Quite the opposite, really. This is an implementation choice to make it simple (well, simple for an ITS emulation...) and not racy. > we must update the test to be architecturally compliant and > logically correct. > > Fix by adding a SYNC command to the selftests ITS library, > then calling SYNC after ITS mapping to ensure mapping > completes before signal_lpi() writes to GITS_TRANSLATER. > > This patch depends on commit a24f7afce048 ("KVM: selftests: > fix MAPC RDbase target formatting in vgic_lpi_stress"), which > is queued in kvmarm/fixes. This sentence has no place in a commit message. > Signed-off-by: Maximilian Dittgen > --- > Validated by the following debug logging to the GITS_CMD_SYNC handler > in vgic_its_handle_command(): > > kvm_info("ITS SYNC command: %016llx %016llx %016llx %016llx\n", > its_cmd[0], its_cmd[1], its_cmd[2], its_cmd[3]); > > Initialized a selftest guest with 4 vCPUs by: > > ./vgic_lpi_stress -v 4 > > Confirmed that an ITS SYNC was successfully called for all 4 vCPUs: > > kvm [5094]: ITS SYNC command: 0000000000000005 0000000000000000 0000000000000000 0000000000000000 > kvm [5094]: ITS SYNC command: 0000000000000005 0000000000000000 0000000000010000 0000000000000000 > kvm [5094]: ITS SYNC command: 0000000000000005 0000000000000000 0000000000020000 0000000000000000 > kvm [5094]: ITS SYNC command: 0000000000000005 0000000000000000 0000000000030000 0000000000000000 > --- > tools/testing/selftests/kvm/arm64/vgic_lpi_stress.c | 4 ++++ > .../testing/selftests/kvm/include/arm64/gic_v3_its.h | 1 + > tools/testing/selftests/kvm/lib/arm64/gic_v3_its.c | 11 +++++++++++ > 3 files changed, 16 insertions(+) > > diff --git a/tools/testing/selftests/kvm/arm64/vgic_lpi_stress.c b/tools/testing/selftests/kvm/arm64/vgic_lpi_stress.c > index 687d04463983..e857a605f577 100644 > --- a/tools/testing/selftests/kvm/arm64/vgic_lpi_stress.c > +++ b/tools/testing/selftests/kvm/arm64/vgic_lpi_stress.c > @@ -118,6 +118,10 @@ static void guest_setup_gic(void) > > guest_setup_its_mappings(); > guest_invalidate_all_rdists(); > + > + /* SYNC to ensure ITS setup is complete */ > + for (cpuid = 0; cpuid < test_data.nr_cpus; cpuid++) > + its_send_sync_cmd(test_data.cmdq_base_va, cpuid); You are making an implementation assumption here. There is nothing in the spec that says that the GICR_TYPER.Processor_Number associated with a given CPU is the same thing as the CPU number that the selftests infrastructure give you. It turns out that KVM makes it so that vcpu_id and Processor_Number are the same thing. But given the blurb above about sticking to the architecture and not relying on implementation details, this is not what I'd expect. Thanks, M. -- Without deviation from the norm, progress is not possible.