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 B9956C04A68 for ; Wed, 27 Jul 2022 10:39:42 +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=aaCRMOoMrYHhMBegG5xdyh+1Rm9vaWQJS661KUY0D70=; b=WuVsh0u/SdHN2L /974YBqFZPeQYCRuI4e4MJ60Goct81tVbOZhG9VBmfdOc3dGpdvNsz1nIN4pJUm4I+PjvltdQ1iFo 0pCXtbT6UFGYnO9SJrfohCmTgJmZ0lUoQHoRKIQKDr6zTEKRES25LGQJOALKYolucQWBOhR2GCoPw fZSZCOxb4Kws2OU0fmz7oByeBP1hUCVcu/srrONoC8kPS/Z+7v7lOaBJ4WtBxqZbfJgzz6rG3bqiy uSqXXzo0q1uANUV5zkNi84jTcGShcUQilJobud2klPYwdKnOuwIUZ584bhue4mWYjERWFlmJCgv6s QUsLVET3Hv1TOeGS/byA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oGeQp-00CTL4-Ew; Wed, 27 Jul 2022 10:38:23 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oGeQl-00CTIm-Ez for linux-arm-kernel@lists.infradead.org; Wed, 27 Jul 2022 10:38:21 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 03925D6E; Wed, 27 Jul 2022 03:38:19 -0700 (PDT) Received: from monolith.localdoman (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 67E743F70D; Wed, 27 Jul 2022 03:38:17 -0700 (PDT) Date: Wed, 27 Jul 2022 11:38:53 +0100 From: Alexandru Elisei To: Marc Zyngier Cc: Oliver Upton , 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: <20220419141012.GB6143@willie-the-truck> <875yjiyka4.wl-maz@kernel.org> <874jz2yja5.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <874jz2yja5.wl-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220727_033819_572758_BF33A08D X-CRM114-Status: GOOD ( 26.63 ) 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 Hi Marc, On Wed, Jul 27, 2022 at 10:52:34AM +0100, Marc Zyngier wrote: > On Wed, 27 Jul 2022 10:30:59 +0100, > Marc Zyngier wrote: > > > > On Tue, 26 Jul 2022 18:51:21 +0100, > > Oliver Upton wrote: > > > > > > Doesn't pinning the buffer also imply pinning the stage 1 tables > > > responsible for its translation as well? I agree that pinning the buffer > > > is likely the best way forward as pinning the whole of guest memory is > > > entirely impractical. > > Huh, I just realised that you were talking about S1. I don't think we > need to do this. As long as the translation falls into a mapped > region (pinned or not), we don't need to worry. > > If we get a S2 translation fault from SPE, we just go and map it. And > TBH the pinning here is just a optimisation against things like swap, > KSM and similar things. The only thing we need to make sure is that > the fault is handled in the context of the vcpu that owns this SPU. > > Alex, can you think of anything that would cause a problem (other than > performance and possible blackout windows) if we didn't do any pinning > at all and just handled the SPE interrupts as normal page faults? PMBSR_EL1.DL might be set 1 as a result of stage 2 fault reported by SPE, which means the last record written is incomplete. Records have a variable size, so it's impossible for KVM to revert to the end of the last known good record without parsing the buffer (references here [1]). And even if KVM would know the size of a record, there's this bit in the Arm ARM which worries me (ARM DDI 0487H.a, page D10-5177): "The architecture does not require that a sample record is written sequentially by the SPU, only that: [..] - On a Profiling Buffer management interrupt, PMBSR_EL1.DL indicates whether PMBPTR_EL1 points to the first byte after the last complete sample record." So there might be gaps in the buffer, meaning that the entire buffer would have to be discarded if DL is set as a result of a stage 2 fault. Also, I'm not sure if you're aware of this, but SPE reports the guest VA in PMBPTR_EL1 (not the IPA) on a fault, so KVM would have to walk the guest's stage 1 tables to service the faults, which would add to the overhead of servicing the fault. Don't know if that makes a difference, just thought I should mention it as another peculiarity of SPE. [1] https://lore.kernel.org/all/Yl7KewpTj+7NSonf@monolith.localdoman/ Thanks, Alex _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel