From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B261F33439D; Fri, 14 Nov 2025 15:42:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763134954; cv=none; b=KQaoGpacW/d0yBCA0ES/lnxK1FACGfr4BQ5x9JNTdQsHP6PnriV77H7ANhs0SjnsF305izSrHpsIZpzyI2NvvTgF3w9SDvfQt4QWVijxA837DkG5a2+XUnuIOXJWX1WZfsa47CVA6WS394KJqXFblv/XX7rtPSsMad0TCYw+vrE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763134954; c=relaxed/simple; bh=/YV/NDL8G+NnwKpf6JduT0mxliwb3hgm6r5W350c8dc=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=H8sPxQwVCLrqIL2aU7HzfVsNGJmllD+xdSO3N4DPBzERo3RK1YlgwvNfD78EACf0BNXr+usbY9diW52kWi4sVMJ7E5lKs/jlSIleVQ8MWnDcif7oFuK13xqG0Rs878N7C7WfnIOo+n/bV6TkM1QHMKv9puBLAQZuWPMR8rBiaTs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=V6MXteKI; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="V6MXteKI" 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) Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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 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.