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 3D6B5C6FA82 for ; Tue, 13 Sep 2022 11:00:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=thP5ZzB09/bumt0vMKmPhH+FI5XiNj8VPx7aIDtWocA=; b=xhCZQPhbuk3Gby SsDB6VJfOCJokO/CAnd7OTFGu4n/mHoIOJAzWsahPj48NvAZmKcmXs43ycJ7r9GG90+BD6CQQf9nt V8S/LZupeM3XQL/QtmbaboL/aMxujRUSlclj5jNp5gK317q5SkstSQ2ya5e5WS/eJWZo6xkaRbWoE yaIa6Vvupca1xzwcSoh+5586qH5YjsdvBKPzir0Up8P+BVKEPZFDRZOTY4jSx9UmzIrRkPRt9JT8v KEUyqW5vIUtw8WBGpIwMEXg9+fWZQWtMlxKGhp3i7d+FqK6MpYpDXg5vbggpBcdkybU1OWU2iuIHn L6drho33Fc411dEOWVYg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oY3dB-0073xJ-Ur; Tue, 13 Sep 2022 10:59:07 +0000 Received: from out1.migadu.com ([91.121.223.63]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oY3d2-0073nC-Gq for linux-arm-kernel@lists.infradead.org; Tue, 13 Sep 2022 10:58:59 +0000 Date: Tue, 13 Sep 2022 11:58:47 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1663066730; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=DyTAIvEIR2Z4eQarHxWKcYP+j8wuMA7QgeATWgvnfbA=; b=tyGXm8tfSdscTpM+3PWqmGoMd2aeNKxA2m5r4w9U3PDCcV/G6dYsKRLQnmbt4AGp4qugOb 5JyHgF6QHNT8B+pmUTxaNTauyQAf+K4QdSLGidEzWgXq/TEog5yu2jyWIvJ8FFd40W3x8N rVbapwWUjS32EcREG7mwKkI59Pd1Fno= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Alexandru Elisei Cc: maz@kernel.org, Will Deacon , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Subject: Re: KVM/arm64: SPE: Translate VA to IPA on a stage 2 fault instead of pinning VM memory Message-ID: References: <20220801170055.GB26471@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220913_035857_355029_C55EFA01 X-CRM114-Status: GOOD ( 25.04 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hey Alex, On Mon, Sep 12, 2022 at 03:50:46PM +0100, Alexandru Elisei wrote: [...] > > Yeah, that would be good to follow up on what other OSes are doing. > > FreeBSD doesn't have a SPE driver. > > Currently in the process of finding out how/if Windows implements the > driver. > > > You'll still have a nondestructive S2 fault handler for the SPE, right? > > IOW, if PMBSR_EL1.DL=0 KVM will just unpin the old buffer and repin the > > new one. > > This is how I think about it: a S2 DABT where DL == 0 can happen because of > something that the VMM, KVM or the guest has done: > > 1. If it's because of something that the host's userspace did (memslot was > changed while the VM was running, memory was munmap'ed, etc). In this case, > there's no way for KVM to handle the SPE fault, so I would say that the > sensible approach would be to inject an SPE external abort. > > 2. If it's because of something that KVM did, that can only be because of a > bug in SPE emulation. In this case, it can happen again, which means > arbitrary blackout windows which can skew the profiling results. I would > much rather inject an SPE external abort then let the guest rely on > potentially bad profiling information. > > 3. The guest changes the mapping for the buffer when it shouldn't have: A. > when the architecture does allow it, but KVM doesn't support, or B. when > the architecture doesn't allow it. For both cases, I would much rather > inject an SPE external abort for the reasons above. Furthermore, for B, I > think it would be better to let the guest know as soon as possible that > it's not following the architecture. > > In conclusion, I would prefer to treat all SPE S2 faults as errors. My main concern with treating S2 faults as a synthetic external abort is how this behavior progresses in later versions of the architecture. SPEv1p3 disallows implementations from reporting external aborts via the SPU, instead allowing only for an SError to be delivered to the core. I caught up with Will on this for a little bit: Instead of an external abort, how about reporting an IMP DEF buffer management event to the guest? At least for the Linux driver it should have the same effect of killing the session but the VM will stay running. This way there's no architectural requirement to promote to an SError. -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel