From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3456D3E315C; Tue, 4 Aug 2026 13:19:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785849570; cv=none; b=V4z5tgau1sYmJlId12peVZPjLIcMynP0OJK+RBxKI9fpoOM+o+YrCzxM7pYvs3vA+PhBLpJwOdNFBcFge8TpY1tACaPWs4AUYFxZwMmoEcE6RD5bBehVKdXJs3nCXTF8pnVRnRDEcWyFsg5ntvFBBZ0mg8R2q3HoTqdjH/vkuPs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785849570; c=relaxed/simple; bh=NvRjT9Esb9qj9dSa9tEJ9J5zZySATr33Mf+UnG5bR7A=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=J3wAIhYCkX72QVzvfkl+j4zNzPtueiOvKhnLWLDfl2s72sZkkgWRt1gZb5lYGLH+IPdMHp5x07JoR9QFeZiPT3++75PNDsy/JVCczv5f22SzC/8c8Wq435cTMmPHt3gAhF9Wq5fSk11A5Np9eKggVmpk8Vds92tMO4Zr30sURds= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=OMrE8whL; arc=none smtp.client-ip=217.140.110.172 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) header.d=arm.com header.i=@arm.com header.b="OMrE8whL" 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 7AC3E1476; Tue, 4 Aug 2026 06:19:24 -0700 (PDT) Received: from [10.57.44.180] (unknown [10.57.44.180]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9B7143F66F; Tue, 4 Aug 2026 06:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1785849568; bh=NvRjT9Esb9qj9dSa9tEJ9J5zZySATr33Mf+UnG5bR7A=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=OMrE8whLpJFQBhveqqIbqAKKQcVRCbg591te1k+SA8QgvhFbMxmJHLashxhYfOgAi juCGKJHjJl2XgtyAskltDE52iESHO+ckTd+1nhO8VxHE6lR4xaULOG3bJ9Zw+6LBpw oUHfurqWDSK1GhkwDpTz/6+EFboAsUiSLESB6vGA= Message-ID: <3b8d49be-f031-4134-bd20-a8c51632f4ad@arm.com> Date: Tue, 4 Aug 2026 14:19:22 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v15 15/37] KVM: arm64: CCA: Handle RMI_EXIT_RIPAS_CHANGE Content-Language: en-GB To: Fuad Tabba Cc: Marc Zyngier , Steven Price , kvm@vger.kernel.org, kvmarm@lists.linux.dev, Catalin Marinas , Will Deacon , James Morse , Oliver Upton , Zenghui Yu , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Joey Gouly , Alexandru Elisei , Christoffer Dall , linux-coco@lists.linux.dev, Ganapatrao Kulkarni , Gavin Shan , Shanker Donthineni , Alper Gun , "Aneesh Kumar K . V" , Emi Kisanuki , Vishal Annapurve , WeiLin.Chang@arm.com, Lorenzo Pieralisi , Quentin Perret References: <20260715142841.80544-1-steven.price@arm.com> <20260715142841.80544-16-steven.price@arm.com> <865x1rcvfw.wl-maz@kernel.org> <86zez3b6ps.wl-maz@kernel.org> <7beafe29-0c5e-418b-8797-190f1850b18a@arm.com> From: Suzuki K Poulose In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Fuad Thanks for your feedback. On 04/08/2026 13:20, Fuad Tabba wrote: > Hi Suzuki, > > + Quentin (who's on leave, but for when he gets back) > > On Mon, 3 Aug 2026 at 16:30, Suzuki K Poulose wrote: > ... >>> I.e don't hack into the API. Use the information you already have to >>> decide whether you need to use the existing API at all. >>> >>> If that cannot be done for whatever reason, then you need to indirect >>> the call with a set of operations that leave the existing code >>> untouched. >> >> Please let us know if you think we need to explore this ^ ? > > FWIW, pKVM already has this kind of indirection: in protected mode, > the kvm_pgtable_stage2_* calls in mmu.c dispatch to the > pkvm_pgtable_stage2_* wrappers through KVM_PGT_FN(), and the callers > don't branch. It is global today because pKVM owns the whole host, but > a per-VM version would let the CCA backend handle the filter and the > IPA aliasing internally, keeping __unmap_stage2_range()'s signature > intact. That should work for pKVM as well. Sure, will explore this option. For the record, the patch here only passes down the "filter" parameter to __unmap_stage2_range() [ though in a different name, only_shared ] and we still handle the aliasing inside the CCA code. Let me explore on this front. Suzuki > > Cheers, > /fuad