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 5DB09C5475B for ; Fri, 1 Mar 2024 19:32:50 +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=uCI4FIaWNMIFvYU8oPtaA31FcLhefTk97SryhYluzuU=; b=29hZ5Ke8WhXtP3 riXgiMXUX6i7KMv6To1oZvFeziSDeTabiFylGuyRW3xiNvFGywGgHv5He8e4Z0jMaeOliXBmweHOF 0gBwxJs13DbUzsODo/Etmjop0gI/744Eiq6+ZgniG7YRPw/cGL29l1cJN63AtKqNpz1AfdZLUGjVl CkfItG2xkoKY5a93yltwT7zOkGzN7AuWJ1SjGSxkeD8P4lbFebst1q5Jo+gez7wfElG5mf70H6LQf GXmc1z/pHwf9OtikafriiAakPj6y1ZBr6ZDA3qFKkFw6GL5yqDsD4zqA6MZOgdDN/XP+dTo7cz2RU C+L+7L3QOx+K6z8jRgig==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rg8cb-00000001jmE-268R; Fri, 01 Mar 2024 19:32:41 +0000 Received: from out-181.mta1.migadu.com ([2001:41d0:203:375::b5]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rg8cY-00000001jl2-2KWa for linux-arm-kernel@lists.infradead.org; Fri, 01 Mar 2024 19:32:40 +0000 Date: Fri, 1 Mar 2024 19:32:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1709321553; 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=HzaS0m3kgMmQ46iSjHCEmGWFSVwIK1lU48lUWC7x/9I=; b=OLlRCv3g39EBv5iR5AVvmplHOaKcHumVgJ+yTHRb96rvEhBl1BvSh+EZ4Ty2oVwQKvhWIs TPgPKoPXmy4Z488b3SBF+Xv2kYKvSlCQFamzQrnSADaBPqjEco6IThlw2IBE+wdyRiLIEG I2c1P/rUyoHO4sPA1h+bMrQIcP+AsWM= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Mark Brown Cc: Marc Zyngier , James Morse , Suzuki K Poulose , Catalin Marinas , Will Deacon , Joey Gouly , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH] KVM: arm64: Only save S1PIE registers when dirty Message-ID: References: <20240301-kvm-arm64-defer-regs-v1-1-401e3de92e97@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240301-kvm-arm64-defer-regs-v1-1-401e3de92e97@kernel.org> X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240301_113238_762235_9713979A X-CRM114-Status: GOOD ( 26.32 ) 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 On Fri, Mar 01, 2024 at 06:05:53PM +0000, Mark Brown wrote: > Currently we save the S1PIE registers every time we exit the guest but > the expected usage pattern for these registers is that they will be > written to very infrequently, likely once during initialisation and then > never updated again. This means that most likely most of our saves of > these registers are redundant. Let's avoid these redundant saves by > enabling fine grained write traps for the EL0 and EL1 PIE registers when > switching to the guest and only saving if a write happened. > > We track if the registers have been written by storing a mask of bits > for HFGWTR_EL2, we may be able to use the same approach for other > registers with similar access patterns. We assume that it is likely > that both registers will be written in quick succession and mark both > PIR_EL1 and PIRE0_EL1 as dirty if either is written in order to minimise > overhead. > > This will have a negative performance impact if guests do start updating > these registers frequently but since the PIE indexes have a wide impact > on the page tables it seems likely that this will not be the case. > > We do not need to check for FGT support since it is mandatory for > systems with PIE. > > Signed-off-by: Mark Brown > --- > I don't have a good sense if this is a good idea or not, or if this is a > desirable implementation of the concept - the patch is based on some > concerns about the cost of the system register context switching. We > should be able to do something similar for some of the other registers. Is there any data beyond a microbenchmark to suggest save elision benefits the VM at all? The idea of baking the trap configuration based on what KVM _thinks_ the guest will do isn't particularly exciting. This doesn't seem to be a one-size-fits-all solution. The overheads of guest exits are extremely configuration dependent, and on VHE the save/restore of EL1 state happens at vcpu_load() / vcpu_put() rather than every exit. There isn't a whole lot KVM can do to lessen the blow of sharing EL1 in the nVHE configuration. Looking a bit further out, the cost of traps will be dramatically higher when running as a guest hypervisor, so we'd want to avoid them if possible... -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel