Re: [PATCH v4 2/2] coco: guest: arm64: Drop dummy RSI platform device stub

[Aneesh Kumar K.V <aneesh.kumar@kernel.org>]

Greg KH <gregkh@linuxfoundation.org> writes:

> On Wed, May 13, 2026 at 02:23:01PM +0530, Aneesh Kumar K.V wrote:
>> Greg KH <gregkh@linuxfoundation.org> writes:
>> 
>> > On Wed, May 13, 2026 at 12:28:12PM +0530, Aneesh Kumar K.V wrote:
>> >> Catalin Marinas <catalin.marinas@arm.com> writes:
>> >> 
>> >> > + Suzuki again
>> >> >
>> >> > On Mon, Apr 27, 2026 at 11:46:15AM +0530, Aneesh Kumar K.V (Arm) wrote:
>> >> >> The SMCCC firmware driver now creates the `arm-smccc` platform device
>> >> >> and also creates the CCA auxiliary devices once the RSI ABI is
>> >> >> discovered. This makes the arch-specific arm64_create_dummy_rsi_dev()
>> >> >> helper redundant. Remove the arm-cca-dev platform device registration
>> >> >> and let the SMCCC probe manage the RSI device.
>> >> >> 
>> >> >> systemd match on platform:arm-cca-dev for confidential vm detection [1].
>> >> >> Losing the platform device registration can break that. Keeping this
>> >> >> removal in its own change makes it easy to revert if that regression
>> >> >> blocks the rollout.
>> >> >> 
>> >> >> [1] https://lore.kernel.org/all/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
>> >> >
>> >> > I wouldn't merge this now given that systemd checks this file. Could we
>> >> > have a symbolic link instead for some time until systemd eventually gets
>> >> > updated (years?).
>> >> >
>> >> 
>> >> I’ll add this in the next revision.
>> >> 
>> >> static int create_rsi_compat_link(struct device *target_dev)
>> >> {
>> >> 	struct kobject *platform_kobj;
>> >> 	/*
>> >> 	 * target_dev is:
>> >> 	 * /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
>> >> 	 * Create compat link /sys/devices/platform/arm-cca-dev
>> >> 	 */
>> >> 	platform_kobj = target_dev->kobj.parent->parent;
>> >
>> > What?  That is crazy, you don't know that is always going to be ok.
>> >
>> >> 	return sysfs_create_link(platform_kobj,
>> >> 				 &target_dev->kobj,
>> >> 				 "arm-cca-dev");
>> >
>> > No, don't do that, if a driver calls a sysfs* function, something is
>> > almost always wrong.  Don't be making random sysfs symlinks please.
>> >
>> 
>> Sure, but could you explain why this is wrong? Below is the full version
>> of the updated patch.
>> 
>> coco: guest: arm64 Replace RSI platform device with compat symlink
>> 
>> The SMCCC firmware driver now creates the arm-smccc platform device and
>> registers the RSI device as an auxiliary device once the RSI ABI has been
>> discovered. This makes the arch-specific arm64 arm-cca-dev platform device
>> redundant.
>> 
>> Remove the arm64 platform device stub and let the SMCCC core manage RSI
>> device creation.
>> 
>> This changes the real device location from the old platform device path to:
>> 
>>   /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
>> 
>> Keep userspace compatibility by creating a sysfs symlink at the old path:
>> 
>>   /sys/devices/platform/arm-cca-dev
>> 
>> A Debian Code Search check found systemd matching on the old
>> platform:arm-cca-dev device path for confidential VM detection. No other
>> userspace dependency on the old platform device path was found, but keeping
>> the compatibility symlink avoids breaking existing systemd-based detection
>> [1].
>> 
>> [1] https://lore.kernel.org/all/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
>
> Don't attempt to put symlinks between random devices in sysfs, that way
> lies madness and you will never get anything fixed.
>
> Just fix userspace, it shouldn't have hard-coded a device path in the
> first place, and you are thinking it would now use a different
> hard-coded device path?  Please do this properly.
>
> Again, there should never be any hard-coded device paths, they are free
> to move around and be renamed at any time.  Use the correct apis instead
> (walking all bus devices, looking at userspace attributes of classes,
> etc.)
>
> So your patch is ok, if you remove the symlink stuff.
>

How about adding /sys/firmware/cca/realm_guest? This would be similar to
/sys/firmware/uv/prot_virt_guest, which is provided on s390.

-aneesh