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 04EBB15B55D; Wed, 28 Aug 2024 08:29:24 +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=1724833766; cv=none; b=Vj3wJEnXAtr6MFRpscCRCIVlzQ8fbYBXfzcmTUrYCPmbUdvIodJxQLdD4CevmeYU5vfu+J/JHfPf4WMqcmBcGCa3hPbLHHkhUzqLLio2sa5OpYD55VXDhwlBmJ0xaCuL5IuYfNI2GOdF7kof4dJbNAL7Y0pyXJcQasP9kzjUnRs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724833766; c=relaxed/simple; bh=2ayyHEqpim6dSZmNkc7u84AxOXt0k/OAEQ+aqlQSSvc=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=ZmqB7Hu1T+VLpgv0QinjZQJ/FlfmBliKzSnh1UVthJRUSvQOmHX4NkuGSreyftxKboxZuD8lh+N6pVLP6920aHNN7mYqiCdJWMyKCrWYdU/miYzK/geI2EuYUtSTTk/1bKa8MD33lgElSPw7GPVGUnNbad2gVP674Vxdmn7+h+w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=l3uCzt+Z; 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="l3uCzt+Z" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7C1CBC4FEFB; Wed, 28 Aug 2024 08:29:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724833764; bh=2ayyHEqpim6dSZmNkc7u84AxOXt0k/OAEQ+aqlQSSvc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=l3uCzt+Zwdh0Jw72xBkF3BGoFPczkR2HeP/8jtT/qTKqlFNUDN9qFAkKsCPTnIl3b 2zB0X8iQXtZYbRKkSoo3kGpqac3s6ckZauSocTOKNEDw4qxCJe7wcTacs6YNUtMxB8 tdpF7VLOcuX6fLu+yVzwwyZNlJuUGPHMt3gg3kFrH3hXxKZr+e9/rZLQ2ySMn9GnM6 wsI6uuVkwBuwCuKHpnBJ/N+QCe14Sp5fJ2l8YnE1BnMXwjrdfWMN1i/kPgBmoZmNyv yWWwUxVfZu7esYifymY5aQG5sWo3iMSsFxwg2UDiH1NJs8Y6MFznlaAil2WJbqrkg4 /Ek8swAUaRPfg== 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 1sjE3O-007UIK-8n; Wed, 28 Aug 2024 09:29:22 +0100 Date: Wed, 28 Aug 2024 09:29:21 +0100 Message-ID: <86frqpvyn2.wl-maz@kernel.org> From: Marc Zyngier To: D Scott Phillips Cc: Alex =?UTF-8?B?QmVubsOpZQ==?= , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, arnd@linaro.org Subject: Re: [PATCH 1/3] ampere/arm64: Add a fixup handler for alignment faults in aarch64 code In-Reply-To: <86frqpk6d7.fsf@scott-ph-mail.amperecomputing.com> References: <20240827130829.43632-1-alex.bennee@linaro.org> <20240827130829.43632-2-alex.bennee@linaro.org> <86frqpk6d7.fsf@scott-ph-mail.amperecomputing.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/29.4 (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=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: scott@os.amperecomputing.com, alex.bennee@linaro.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, arnd@linaro.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Tue, 27 Aug 2024 22:23:16 +0100, D Scott Phillips wrote: >=20 > Alex Benn=C3=A9e writes: >=20 > > From: D Scott Phillips > > > > A later patch will hand out Device memory in some cases to code > > which expects a Normal memory type, as an errata workaround. > > Unaligned accesses to Device memory will fault though, so here we > > add a fixup handler to emulate faulting accesses, at a performance > > penalty. > > > > Many of the instructions in the Loads and Stores group are supported, > > but these groups are not handled here: > > > > * Advanced SIMD load/store multiple structures > > * Advanced SIMD load/store multiple structures (post-indexed) > > * Advanced SIMD load/store single structure > > * Advanced SIMD load/store single structure (post-indexed) >=20 > Hi Alex, I'm keeping my version of these patches here: >=20 > https://github.com/AmpereComputing/linux-ampere-altra-erratum-pcie-65 >=20 > It looks like the difference to the version you've harvested is that > I've since added handling for these load/store types: >=20 > Advanced SIMD load/store multiple structure > Advanced SIMD load/store multiple structure (post-indexed) > Advanced SIMD load/store single structure > Advanced SIMD load/store single structure (post-indexed) >=20 > I've never sent these patches because in my opinion there's too much > complexity to maintain upstream for this workaround, though now they're > here so we can have that conversation. >=20 > Finally, I think a better approach overall would have been to have > device memory mapping in the stage 2 page table, then booting with pkvm > would have this workaround for both the host and guests. I don't think > that approach changes the fact that there's too much complexity here. That's a rather bad idea. You are then asking the hypervisor to proxy the accesses that the guest performs. Two issues with that: - the hypervisor now needs to keep a mapping of the device in its own S1, which is pretty fun given that the mapping can change location if BARs get remapped behind the hypervisor's back. - you are asking the hypervisor to trust the nature of the access. If you get an error response from the device because the access cannot be handled (the size, for example), you are likely to get an SError, which will bring the whole system down. You can do that to some extent for when you completely control the programming model of the devices. KVM does that for GICv2, for example. But in general? No. Furthermore, adding an instruction emulator to KVM is totally out of the question. If something has to be emulated, that's for userspace to take care of it. Any notion of performance has gone through the window anyway, so that doesn't make much of a difference. Thanks, M. --=20 Without deviation from the norm, progress is not possible.