From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 F0754383984; Tue, 18 Aug 2026 16:06:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787069196; cv=none; b=K+M16H+B3INGe/+ceg+mEZoe//HLITc5kJlzXfj4G3Iynk0hlUCXb2xpy9E6ChOhz7NDeU7YzYLS1k/yp/XA2crPRsVT6A5tMWcchehlVJPEeCVX8uDtZds2m43nGQxxDJ1QZx+/pgWUnGVxlYq8q71vZr1vfzBL8bs7JFh4CVk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787069196; c=relaxed/simple; bh=ph9g+CbK1ePxcfmkzABPDqEQhX2TRZDo6SGn1UcmW5k=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=UgDOqkn8QRyTVHt9BkgmaCcIqR7UjBShFZOREwk0L5yaB6rjgXeh29P0ZJoYXlj5EIv9LVD1Ch0y3p0Rx79l4kK3CwWhTlJOQqio5mB7yuj0Zu0l+vmkF2Ri027pTWnyjzMXUUS7v/zzRu3NMMbrtWID4kSDHIcamJxUnu8B0ic= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=G93aZ46l; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="G93aZ46l" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 84BFA1F000E9; Tue, 18 Aug 2026 16:06:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787069194; bh=UgrJJhQc/4e7NnJYwwwc6uJ+1vo6VfZ5bWm04iyllPY=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=G93aZ46lsZnhmzymQMOvP8OGaz3ngAwqRS6s3U3nTzxkfsRRZ+ZyDXYD548mY+ooz XvLssf9mIg+c59peoFQwxAZhXKxZoKEGJlyfivBI0L5OgGojkTiSXWnah38Gi6WWX8 Ov+VG+lIRWhAt//OukxR35gEOjanQKPnLBqnau8P001DH3bMs0JwqavuS1LZIIxeLB FKKjAloBj2SXLRAF0t0yUkROWW1T9C+w8Gr6jSXBq8PXL4kIctNKGG5PB4NU3lteLE JuN4N0tsC86lBNmqa2X2RImisHyIkqtFI9ueQQm0hnem2eRwvM4YzziUh6yuF3YOig XpKlTILzla2fg== 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 1wwMKe-0000000Gh5W-2L5E; Tue, 18 Aug 2026 16:06:32 +0000 Date: Tue, 18 Aug 2026 17:06:32 +0100 Message-ID: <86bjaz5s6v.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: Oliver Upton , Joey Gouly , Steffen Eiden , Suzuki K Poulose , Zenghui Yu , Will Deacon , Sascha Bischoff , Sebastian Ene , kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 3/4] KVM: arm64: vgic-its: Don't save collections the table cannot hold In-Reply-To: References: <20260807104102.2410744-1-fuad.tabba@linux.dev> <20260807104102.2410744-4-fuad.tabba@linux.dev> <87ecg9owwa.wl-maz@kernel.org> 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: linux-kernel@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: fuad.tabba@linux.dev, oupton@kernel.org, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, will@kernel.org, sascha.bischoff@arm.com, sebastianene@google.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Mon, 17 Aug 2026 19:21:24 +0100, Fuad Tabba wrote: > > Hi Marc, > > Sorry for the slow reply, I was away. No worries. > > On Sat, 8 Aug 2026 at 09:09, Marc Zyngier wrote: > ... > > > A guest that disables the ITS and rewrites GITS_BASER with fewer pages, > > > VALID still set, keeps every collection it mapped against the larger > > > table: KVM stores the new BASER unconditionally and frees the list only > > > when VALID is cleared. > > > > But isn't that the *real* problem? Shouldn't we instead nuke the > > collections entirely and go through a reload sequence? > > Agreed, that is the problem. The fix belongs in vgic_mmio_write_its_baser(). > > Should it drop everything, or only the collections that no longer fit? > On a shrink in place the low ICIDs are still in the table. Or is no > realistic guest doing this, so the simpler rule wins? I can do the > unconditional drop if you prefer. Whatever is the simplest thing. I don't think it is common to update the BASER registers (Linux certainly does it exactly once), and if that means there will be a small hickup on things like kexec handover, so be it. Thinking of it a bit more: the format of the table is not architected. So a write to the register with a different value is allowed to result in data loss (for all the guest knows, this could be a linked list starting from the last page...). So purging all collections (and therefore all mappings) would be acceptable, as there no guarantee this is now fit for purpose. This would make both save and restore succeed, and be really quick! > > > Validate each collection against the current table with > > > vgic_its_check_id() and return -EINVAL, as vgic_its_save_device_tables() > > > does for devices. Collection IDs are unique and the collection table is > > > never indirect, so the check also bounds the walk. > > > > I think returning -EINVAL here was a mistake, as it aborts the save > > procedure that userspace should be able to issue reliably, even if > > that means the state is crap. I don't think we should expand that > > behaviour any further. > > Fair enough. Either way the check goes with the fix rather than being > expanded: MAPC, MAPTI and the restore path already validate against > the current table. > > vgic_its_save_device_tables() is harder: with an indirect table the > guest can invalidate an L1 entry without touching GITS_BASER, so that > check can still fire. Skip the device rather than fail the save? Skipping the devices that fall into an unmapped page looks fine. After all, the guest is messing with itself, and I have no sympathy for it. Thanks, M. -- Without deviation from the norm, progress is not possible.