From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793274898; b=lHaNqviAXlkuiBMxz3+Cc97pN0R11KGBd7Z8dbyNFFRR/mhFMDPW1scoG+MhG5abcp0X ruNr9oNPM4JeltwOwU/jESqv4IqE8cwPVhbEDr6mWTCpjva2pYwqUJ+scOQhpadTubRdB ZPgfkaQh753j9Ym2TVpDX6c3/kId/UfpVT1LpeG+1uZnqC/GFXrOjsrof3fkkRXpuaz4G w/veChhFJQeSoulS43nwZOKfhjSKuNaF4enP2FvQw+dFlprMh2f91hRn9Ag1aAl9Eho6W TXZGwnJHMpRRlQsTr6+MfsW5ETG1Bw0F9fn36f/m43MysfjqqDVpXBhmmrypow5GCEQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793274898; h=DMARC-Filter:Received:Received:DKIM-Signature:From:To:Cc:Subject: Date:Message-ID:X-Mailer:In-Reply-To:References:MIME-Version: Content-Type:Content-Disposition:Content-Transfer-Encoding; bh=h/fSgV0zO2t1wf4b6fHc2vLg5ezMBdguHQgR0SISKi0=; b=iGXZW39z7fUxMBQ+tH2mjY6T8J8Ra9Am9QZaohAKpFpSeCqFQqPrpGoeOr9le+ewnB0U NWGMftwOR/B4Fr6i/BBvmrVXfGJZjXlkgxq84eFQ/3pSqAoLi5yQD0P8I0dnQdHTXBDTu gOO2v9AesaJA6Kng03x4vSN0FPLCZToVFyY1TM14dOPiHx3f+oo+LNtXmQxLRaaXZvOd9 erCsy8qpBXWIqDWlMsA+j/LJUfQb+i73ABurIUNtKllEz5SiXiJdNgRQ9TX30kgHo658e /1GmDYyk3W4jczCVJgdOCgAWNg/Oi7/GVxjdpX3r7zfxF2wqMQofuWhnEvzPN2O23gA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=foss header.b=I8KFvowK; arc=none smtp.remote-ip=217.140.110.172 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2D153606A31D for ; Thu, 29 Oct 2026 11:54:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 2D153606A31D Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=foss header.b=I8KFvowK 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 DE9161BB2; Thu, 29 Oct 2026 04:54:52 -0700 (PDT) Received: from LeoBrasDK.cambridge.arm.com (LeoBrasDK.cambridge.arm.com [10.2.212.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EB64F3F59E; Thu, 29 Oct 2026 04:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1793274896; bh=qViMHAB2Kt/5NwjHfumEcn0tMJKp0+ZDStMShfsDLVU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=I8KFvowKpOVUFgo6sy3X5C6rFJhaRyJnA25w33Wgx/17gKnukyLRomu1Pf1yI0Iof lcQnpe0Abth0EmgQxlHKa3rA+Kef/8Nq0SM2/MdkIDBqHJb0lHq64HxFrw1tmpcN78 kDWC+g8JQgHOjQKJWsPFk6CCDbTnj7J797e+n+f4= From: Leonardo Bras To: Tian Zheng Cc: Leonardo Bras , liuyonglong , Oliver Upton , Marc Zyngier , Fuad Tabba , Joey Gouly , Steffen Eiden , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Mark Rutland , Raghavendra Rao Ananta , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 5/5] KVM: arm64: Enable HAFDBS for guests not on migration Date: Thu, 29 Oct 2026 11:54:49 +0000 Message-ID: X-Mailer: git-send-email 2.56.0 In-Reply-To: <52945586-8c5c-4991-bd92-fe02aaf79fbe@huawei.com> References: <3e464bef-8dfe-44a3-afea-3c276ae87cd8@huawei.com> <8eaaba87-7881-49c4-a76a-51dec2f29ffc@huawei.com> <52945586-8c5c-4991-bd92-fe02aaf79fbe@huawei.com> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 8bit On Thu, Oct 29, 2026 at 10:54:24AM +0800, Tian Zheng wrote: > Hi Leo, > > I've read your discussion with Oliver on DBM RFC v2. As a suggestion, > maybe we should go with Oliver's approach, i.e. revert to the v1 scheme > and continue fixing from there. Hi Tian, I have been reading a bit more about permission indirection to try figuring out a way that the change may work for both ways. The problem with the previous approach is that it assume DBM=write at all times, which is not architecturally correct. Having DBM=write only on HAFDBS=on as suggested would require us to transverse the whole pagetable to convert encodings when we enable/disable it, which can be quite expensive. One option would be to always enable HAFDBS when system supports HDBSS, but I still have to figure out if that causes any performance regression before suggesting. The option I am pursuing is thinking on an unified code path for direct permissison (both HACDBS=on and HACDBS=off) so we don't have to convert between them, neither worry about the impact of HAFDBS=on on performance. I will reply on the thread once I figure one of those options out. Thanks! Leo