Re: [RFC PATCH v1 1/2] KVM: arm64: CCA: Add support for configuring the Realm MEC policy

[Kohei Enju <enju.kohei@fujitsu.com>]

On 11/02 15:57, Suzuki K Poulose wrote:
> Hi Kohei,
> 
> On 02/11/2026 15:19, Kohei Enju wrote:
> > Hi Suzuki,
> > 
> > I sent the message below off-list a few weeks ago, but I'm following up
> > on-list in case it didn't reach you.
> > 
> > Since then, I've started reworking the series based on the
> > kvm_device_attr approach you suggested, and I'm currently testing it
> > against v23 of the CCA host support.
> > 
> > I'd still appreciate any feedback on the ABI direction, as well as
> > whether you see any concerns with posting the RFC series while the host
> > support is not yet upstream.
> > 
> > Thanks,
> > Kohei
> > 
> > On Fri, Oct 9, 2026 at 03:15:23PM +0900, Kohei Enju wrote:
> > > On 07/31 14:09, Kohei Enju wrote:
> > > > On 07/29 12:47, Suzuki K Poulose wrote:
> > > > > Hello
> > > > > 
> > > > > Thanks for sending the patch. Please find my comments inline below.
> > > > > 
> > > > > 
> > > > > On 24/07/2026 10:40, Kohei Enju wrote:
> > > > > > Introduce the KVM_ARM_RMI_CONFIG ioctl to allow userspace to configure
> > > > > > Realm VM parameters before the Realm is created.
> > > > > 
> > > > > This approach is something we tried in the past. Another option is to
> > > > > add these as kvm_device_attr for the KVM VM, under a new group, e.g.,
> > > > > KVM_ARM_VM_RMI_CTRL and add the following attributes :
> > > > > 
> > > > > KVM_ARM_VM_RMI_CTRL_RPV 		-> Realm Personalization Value
> > > > > KVM_ARM_VM_RMI_CTRL_MEASUREMENT_ALGO	-> Measuerment algo
> > > > > KVM_ARM_VM_RMI_CTRL_MEC_PRIVATE		-> Private MEC Policy. By default to shared
> > > > > ?
> > > > 
> > > > Hi Suzuki, thanks for suggesting another option. That looks good to me,
> > > > and I'd be happy with either approach.
> > > > Anyway I'd like to wait for feedback from the maintainers and other
> > > > reviewers.
> > > 
> > > Hi Suzuki,
> > > 
> > > I'm thinking of respinning the MEC policy series as RFC v2, as you
> > > mentioned in the Core Collective WG last month.
> > > 
> > > For the ABI, I'm planning to switch to the kvm_device_attr-based
> > > approach you suggested instead of introducing a new VM ioctl. Before I
> > > start reworking the series, do you have any concerns with that
> > > direction?
> 
> ...
> 
> 
> > > 
> > > One other point is that the series still depends on the CCA host
> > > support, which is not upstream yet. As a result, tools such as Sashiko
> > > would likely be unable to identify the correct base tree and may not be
> > > able to provide useful automated review feedback.
> > > 
> > > Personally, I think this is acceptable since the series is still RFC and
> > > the primary goal is to get feedback on the ABI and overall design rather
> > > than seeking integration at this stage. However, I am aware that posting
> > > patches on top of non-upstream trees can sometimes be problematic from a
> > > review perspective.
> > > 
> > > Do you have any concerns about posting an RFC series in this situation,
> > > or would you prefer that I wait until the host support lands upstream?
> 
> It would be useful to have the RFC on the list to get an idea on shaping
> the UABI. It may also be useful for people to verify the end-to-end
> stack, including the remote attestation flow. (the branch we have is
> ancient)

Thanks. I'll post RFC v2 soon, based on the following branch:
  https://gitlab.arm.com/linux-arm/linux-cca
  branch: cca-host-mm/v1/integration

> 
> But nothing else, i.e, code correctness or functional reviews
> etc (that rules out meaningful Sashiko reviews etc).

Thanks for the clarification.

Thanks,
Kohei