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 2C1C4522A for ; Sun, 27 Apr 2025 16:43:23 +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=1745772204; cv=none; b=RKULeMsS8iQuf/FJRfA3AwRp0hbjJw7jzmUwQoG/OYn05Thcwt0ZVQ1Z3QqDeUL57D25s+9GmRYmCzv7zt2SY8IH3eDlXlhiJijvPs26+QScpQLYlplKw/hqYt4iJEUCB1DjAWkC79oFWHHfCI6/byKXxlY35dNDMZumPocApCM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745772204; c=relaxed/simple; bh=tPOIYQvlckSn9ZlJWzhqui3/DPJ7x4EqYVgyVa6Zg8w=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=hctQ7SGdwoALVS9qv8JITY39+LUlmoC+sOHNeJMwJQmhtm6mGIM5BwjXh3HJmZvYqTd60O0WGZzzfd+BT5NYTvA+a51keFtWIdH/IyRh2QwzS0zN9MHEbEp08eGMT2FlS1qcAZob9n+xlmB4JrMGCAWtP2DIrJPVZHMg7pjfS5A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OHXGvfoL; 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="OHXGvfoL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 883B9C4CEE3; Sun, 27 Apr 2025 16:43:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745772203; bh=tPOIYQvlckSn9ZlJWzhqui3/DPJ7x4EqYVgyVa6Zg8w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=OHXGvfoLXxYY91p48wm7+XeUIH0vDOfmxN1etUlTlYoeObj70nLyCFLkBzkiTz+SG rwwB3uER+bA8uHcZrMMGjr6388/o6TGB/W3FtjByoecMcgDJqv0guLcSY946r9oqCB IffEyyzwx6cX9j5VYd/3UCOfqx9uJQ7QsPLdA+qAVDRIBAsXQOm8R+bn+w6VUFLCFn nCqKqQ4bJWrRwIDFNuDbw/9sb4B271kfDx+9jiofT9j/qtQpplxGSaJmtZ7Ct0llsF bipW4+vgBjK+7CB3egAi32YncPI9JfgTIFGG+z1HPyXrLvghuDFUtAtz15q4VB3ICq VoBwv5d4A/xpQ== 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.95) (envelope-from ) id 1u9567-009JWO-GZ; Sun, 27 Apr 2025 17:43:21 +0100 Date: Sun, 27 Apr 2025 17:43:18 +0100 Message-ID: <86cycxk121.wl-maz@kernel.org> From: Marc Zyngier To: David Woodhouse Cc: Ilias Stamatis , kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, eric.auger@redhat.com, andre.przywara@arm.com, will@kernel.org, jgrall@amazon.co.uk, ugurus@amazon.co.uk, nh-open-source@amazon.com Subject: Re: [RFC] ARM vGIC-ITS tables serialization when running protected VMs In-Reply-To: <6ff7bf8388303c75092d0cc1078d40f018d2bbc4.camel@infradead.org> References: <20250414111244.153528-1-ilstam@amazon.com> <867c3llt43.wl-maz@kernel.org> <94fb9d4adb81f824912ee23a296776aa07873354.camel@infradead.org> <6ff7bf8388303c75092d0cc1078d40f018d2bbc4.camel@infradead.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/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: dwmw2@infradead.org, ilstam@amazon.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, eric.auger@redhat.com, andre.przywara@arm.com, will@kernel.org, jgrall@amazon.co.uk, ugurus@amazon.co.uk, 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 Tue, 22 Apr 2025 11:47:46 +0100, David Woodhouse wrote: >=20 > [1 ] > On Tue, 2025-04-15 at 10:44 +0100, David Woodhouse wrote: > > =C2=A0 > >=20 > > > > Another issue is that it's actually hard for the lowvisor to know w= here these > > > > tables live without trusting the EL1 host which virtualizes the ITS= . It is > > > > especially hard knowing the locations of the ITTs (compared to > > > > Collection/Device tables) because that probably means having to par= se the ITS > > > > command queue from EL2 which is complex and undesirable. > > > >=20 > > > > # An alternative: Serializing ITTs into a userspace buffer > > >=20 > > > NAK. > > >=20 > > > Share the page-aligned memory with the rest of the hypervisor, and use > > > the existing API. > >=20 > > That seems like a bad choice. All this is just using guest memory to > > store KVM's state. > >=20 > > Yes, the guest provides a buffer which the virtual hardware *may* use > > if it wants, but with no IOMMU or access control defined in the > > specification. > >=20 > > It seems like it would be much cleaner just to let KVM pass its state > > up to userspace for serialization like we do for all *other* KVM state, > > which is what Ilias is proposing. >=20 > Ping? >=20 > Redefining the GIC specification to implicitly share whole pages with > the hypervisor in a protected guest, when they happen to have an ITT > somewhere inside the page, seems like a very bad idea. Did you have > some proposed wording for the specification update though, if that's > the approach you're proposing? That's already a requirement for CCA when used with GICv3/GICv4. > And *implementing* it by making the lowvisor snoop on the ITS command > queue is also awful. Not only the command queue. *ANY* RD and ITS access. If you don't, it is rather easy for the host to use the GIC to repaint your privileged code and confidential guest, one bit at a time. But that has nothing to do with sharing the ITT memory, which is only manipulated by the KVM emulation. M. --=20 Without deviation from the norm, progress is not possible.