Register a platform device if the CCA DA feature is supported.
A driver for this platform device will further drive the CCA DA workflow.
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
arch/arm64/include/asm/rmi_smc.h | 3 +++
arch/arm64/kvm/rme.c | 16 ++++++++++++++++
2 files changed, 19 insertions(+)
diff --git a/arch/arm64/include/asm/rmi_smc.h b/arch/arm64/include/asm/rmi_smc.h
index 504009a42035..42708d500048 100644
--- a/arch/arm64/include/asm/rmi_smc.h
+++ b/arch/arm64/include/asm/rmi_smc.h
@@ -12,6 +12,8 @@
#include <linux/arm-smccc.h>
+#define RMI_DEV_NAME "arm-rmi-dev"
+
#define SMC_RMI_CALL(func) \
ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
ARM_SMCCC_SMC_64, \
@@ -87,6 +89,7 @@ enum rmi_ripas {
#define RMI_FEATURE_REGISTER_0_GICV3_NUM_LRS GENMASK(37, 34)
#define RMI_FEATURE_REGISTER_0_MAX_RECS_ORDER GENMASK(41, 38)
#define RMI_FEATURE_REGISTER_0_Reserved GENMASK(63, 42)
+#define RMI_FEATURE_REGISTER_0_DA BIT(42)
#define RMI_REALM_PARAM_FLAG_LPA2 BIT(0)
#define RMI_REALM_PARAM_FLAG_SVE BIT(1)
diff --git a/arch/arm64/kvm/rme.c b/arch/arm64/kvm/rme.c
index ec8093ec2da3..d1c147aba2ed 100644
--- a/arch/arm64/kvm/rme.c
+++ b/arch/arm64/kvm/rme.c
@@ -4,6 +4,7 @@
*/
#include <linux/kvm_host.h>
+#include <linux/platform_device.h>
#include <asm/kvm_emulate.h>
#include <asm/kvm_mmu.h>
@@ -1724,6 +1725,18 @@ int kvm_init_realm_vm(struct kvm *kvm)
return 0;
}
+static struct platform_device cca_host_dev = {
+ .name = RMI_DEV_NAME,
+ .id = PLATFORM_DEVID_NONE
+};
+
+static void rmm_tsm_init(void)
+{
+ if (!platform_device_register(&cca_host_dev))
+ pr_info("CCA host DA platform device initialized.\n");
+
+}
+
void kvm_init_rme(void)
{
if (PAGE_SIZE != SZ_4K)
@@ -1737,6 +1750,9 @@ void kvm_init_rme(void)
if (WARN_ON(rmi_features(0, &rmm_feat_reg0)))
return;
+ if (rme_has_feature(RMI_FEATURE_REGISTER_0_DA))
+ rmm_tsm_init();
+
if (rme_vmid_init())
return;
--
2.43.0On Mon, 28 Jul 2025 19:21:48 +0530
"Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org> wrote:
> Register a platform device if the CCA DA feature is supported.
> A driver for this platform device will further drive the CCA DA workflow.
>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
Few trivial things
> diff --git a/arch/arm64/kvm/rme.c b/arch/arm64/kvm/rme.c
> index ec8093ec2da3..d1c147aba2ed 100644
> --- a/arch/arm64/kvm/rme.c
> +++ b/arch/arm64/kvm/rme.c
> @@ -4,6 +4,7 @@
> */
>
> #include <linux/kvm_host.h>
> +#include <linux/platform_device.h>
>
> #include <asm/kvm_emulate.h>
> #include <asm/kvm_mmu.h>
> @@ -1724,6 +1725,18 @@ int kvm_init_realm_vm(struct kvm *kvm)
> return 0;
> }
>
> +static struct platform_device cca_host_dev = {
Hmm. Greg is getting increasingly (and correctly in my view) grumpy with
platform devices being registered with no underlying resources etc as glue
layers. Maybe some of that will come later.
> + .name = RMI_DEV_NAME,
> + .id = PLATFORM_DEVID_NONE
Add trailing comma. More than possible something else will be added after this.
> +};
> +
> +static void rmm_tsm_init(void)
> +{
> + if (!platform_device_register(&cca_host_dev))
> + pr_info("CCA host DA platform device initialized.\n");
Noisy as we should be able to tell that in a bunch of other ways.
> +
Excess blank line.
> +}
On Tue, Jul 29, 2025 at 06:10:45PM +0100, Jonathan Cameron wrote:
> > +static struct platform_device cca_host_dev = {
> Hmm. Greg is getting increasingly (and correctly in my view) grumpy with
> platform devices being registered with no underlying resources etc as glue
> layers. Maybe some of that will come later.
Is faux_device a better choice? I admit to not knowing entirely what
it is for..
But alternatively, why do we need a dummy "hw" struct device at all?
Typically a subsystem like TSM should be structured to create its own
struct devices..
I would expect this to just call 'register tsm' ?
Jason
Jason Gunthorpe <jgg@ziepe.ca> writes:
> On Tue, Jul 29, 2025 at 06:10:45PM +0100, Jonathan Cameron wrote:
>
>> > +static struct platform_device cca_host_dev = {
>> Hmm. Greg is getting increasingly (and correctly in my view) grumpy with
>> platform devices being registered with no underlying resources etc as glue
>> layers. Maybe some of that will come later.
>
> Is faux_device a better choice? I admit to not knowing entirely what
> it is for..
>
> But alternatively, why do we need a dummy "hw" struct device at all?
> Typically a subsystem like TSM should be structured to create its own
> struct devices..
>
> I would expect this to just call 'register tsm' ?
>
The goal is to have tsm class device to be parented by the platform
device.
# ls -al
total 0
drwxr-xr-x 2 root root 0 Jan 13 06:07 .
drwxr-xr-x 23 root root 0 Jan 1 00:00 ..
lrwxrwxrwx 1 root root 0 Jan 13 06:07 tsm0 -> ../../devices/platform/arm-rmi-dev/tsm/tsm0
# pwd
/sys/class/tsm
-aneesh
On Wed, 30 Jul 2025 14:12:26 +0530
"Aneesh Kumar K.V" <aneesh.kumar@kernel.org> wrote:
> Jason Gunthorpe <jgg@ziepe.ca> writes:
>
> > On Tue, Jul 29, 2025 at 06:10:45PM +0100, Jonathan Cameron wrote:
> >
> >> > +static struct platform_device cca_host_dev = {
> >> Hmm. Greg is getting increasingly (and correctly in my view) grumpy with
> >> platform devices being registered with no underlying resources etc as glue
> >> layers. Maybe some of that will come later.
> >
> > Is faux_device a better choice? I admit to not knowing entirely what
> > it is for..
I'll go with a cautious yes to faux_device. This case of a glue device
with no resources and no reason to be on a particular bus was definitely
the intent but I'm not 100% sure without trying it that we don't run
into any problems.
Not that many examples yet, but cpuidle-psci.c looks like a vaguely similar
case to this one.
All it really does is move the location of the device and
smash together the device registration with probe/remove.
That means the device disappears if probe() fails, which is cleaner
in many ways than leaving a pointless stub behind.
Maybe it isn't appropriate it if is actually useful to rmmod/modprobe the
driver.
+CC Greg on basis I may have wrong end of the stick ;)
> >
> > But alternatively, why do we need a dummy "hw" struct device at all?
> > Typically a subsystem like TSM should be structured to create its own
> > struct devices..
> >
> > I would expect this to just call 'register tsm' ?
> >
>
> The goal is to have tsm class device to be parented by the platform
> device.
>
> # ls -al
> total 0
> drwxr-xr-x 2 root root 0 Jan 13 06:07 .
> drwxr-xr-x 23 root root 0 Jan 1 00:00 ..
> lrwxrwxrwx 1 root root 0 Jan 13 06:07 tsm0 -> ../../devices/platform/arm-rmi-dev/tsm/tsm0
> # pwd
> /sys/class/tsm
>
> -aneesh
>
On Wed, Jul 30, 2025 at 11:38:27AM +0100, Jonathan Cameron wrote:
> On Wed, 30 Jul 2025 14:12:26 +0530
> "Aneesh Kumar K.V" <aneesh.kumar@kernel.org> wrote:
>
> > Jason Gunthorpe <jgg@ziepe.ca> writes:
> >
> > > On Tue, Jul 29, 2025 at 06:10:45PM +0100, Jonathan Cameron wrote:
> > >
> > >> > +static struct platform_device cca_host_dev = {
> > >> Hmm. Greg is getting increasingly (and correctly in my view) grumpy with
> > >> platform devices being registered with no underlying resources etc as glue
> > >> layers. Maybe some of that will come later.
> > >
> > > Is faux_device a better choice? I admit to not knowing entirely what
> > > it is for..
>
> I'll go with a cautious yes to faux_device. This case of a glue device
> with no resources and no reason to be on a particular bus was definitely
> the intent but I'm not 100% sure without trying it that we don't run
> into any problems.
>
> Not that many examples yet, but cpuidle-psci.c looks like a vaguely similar
> case to this one.
>
> All it really does is move the location of the device and
> smash together the device registration with probe/remove.
> That means the device disappears if probe() fails, which is cleaner
> in many ways than leaving a pointless stub behind.
>
> Maybe it isn't appropriate it if is actually useful to rmmod/modprobe the
> driver.
Yeah, exactly. Can a TSM driver even be modular? If it has to be built
in then there is no reason to do this:
> > The goal is to have tsm class device to be parented by the platform
> > device.
IMHO the only real point of that is to trigger module autoloading.
Otherwise the tsm core should accept NULL as the parent pointer during
registration, it probably already does..
Jason
Jason Gunthorpe wrote:
> On Wed, Jul 30, 2025 at 11:38:27AM +0100, Jonathan Cameron wrote:
> > On Wed, 30 Jul 2025 14:12:26 +0530
> > "Aneesh Kumar K.V" <aneesh.kumar@kernel.org> wrote:
> >
> > > Jason Gunthorpe <jgg@ziepe.ca> writes:
> > >
> > > > On Tue, Jul 29, 2025 at 06:10:45PM +0100, Jonathan Cameron wrote:
> > > >
> > > >> > +static struct platform_device cca_host_dev = {
> > > >> Hmm. Greg is getting increasingly (and correctly in my view) grumpy with
> > > >> platform devices being registered with no underlying resources etc as glue
> > > >> layers. Maybe some of that will come later.
> > > >
> > > > Is faux_device a better choice? I admit to not knowing entirely what
> > > > it is for..
> >
> > I'll go with a cautious yes to faux_device. This case of a glue device
> > with no resources and no reason to be on a particular bus was definitely
> > the intent but I'm not 100% sure without trying it that we don't run
> > into any problems.
> >
> > Not that many examples yet, but cpuidle-psci.c looks like a vaguely similar
> > case to this one.
> >
> > All it really does is move the location of the device and
> > smash together the device registration with probe/remove.
> > That means the device disappears if probe() fails, which is cleaner
> > in many ways than leaving a pointless stub behind.
> >
> > Maybe it isn't appropriate it if is actually useful to rmmod/modprobe the
> > driver.
>
> Yeah, exactly. Can a TSM driver even be modular? If it has to be built
> in then there is no reason to do this:
For example, CRYPTO_DEV_CCP_DD, the AMD PCI device driver that will call
tsm_register(), is already modular.
> > > The goal is to have tsm class device to be parented by the platform
> > > device.
>
> IMHO the only real point of that is to trigger module autoloading.
Right. For TDX, and I expect CCA as well, the arch code that knows that
PCI/TSM functionality is available and can register a device, may be
running too early to attach a driver to that device.
I.e. I would like to just use faux_device, but without the ability to do
EPROBE_DEFER, for example to await the plaform IOMMU driver. It needs to
move to its own bus so the attach event can be handled at a better time.
> Otherwise the tsm core should accept NULL as the parent pointer during
> registration, it probably already does..
Yes, NULL @parent "just works" with tsm_register().
However, I expect all tsm_register() callers to be from modular drivers.
<dan.j.williams@intel.com> writes:
> Jason Gunthorpe wrote:
>> On Wed, Jul 30, 2025 at 11:38:27AM +0100, Jonathan Cameron wrote:
>> > On Wed, 30 Jul 2025 14:12:26 +0530
>> > "Aneesh Kumar K.V" <aneesh.kumar@kernel.org> wrote:
>> >
>> > > Jason Gunthorpe <jgg@ziepe.ca> writes:
>> > >
>> > > > On Tue, Jul 29, 2025 at 06:10:45PM +0100, Jonathan Cameron wrote:
>> > > >
>> > > >> > +static struct platform_device cca_host_dev = {
>> > > >> Hmm. Greg is getting increasingly (and correctly in my view) grumpy with
>> > > >> platform devices being registered with no underlying resources etc as glue
>> > > >> layers. Maybe some of that will come later.
>> > > >
>> > > > Is faux_device a better choice? I admit to not knowing entirely what
>> > > > it is for..
>> >
>> > I'll go with a cautious yes to faux_device. This case of a glue device
>> > with no resources and no reason to be on a particular bus was definitely
>> > the intent but I'm not 100% sure without trying it that we don't run
>> > into any problems.
>> >
>> > Not that many examples yet, but cpuidle-psci.c looks like a vaguely similar
>> > case to this one.
>> >
>> > All it really does is move the location of the device and
>> > smash together the device registration with probe/remove.
>> > That means the device disappears if probe() fails, which is cleaner
>> > in many ways than leaving a pointless stub behind.
>> >
>> > Maybe it isn't appropriate it if is actually useful to rmmod/modprobe the
>> > driver.
>>
>> Yeah, exactly. Can a TSM driver even be modular? If it has to be built
>> in then there is no reason to do this:
>
> For example, CRYPTO_DEV_CCP_DD, the AMD PCI device driver that will call
> tsm_register(), is already modular.
>
>> > > The goal is to have tsm class device to be parented by the platform
>> > > device.
>>
>> IMHO the only real point of that is to trigger module autoloading.
>
> Right. For TDX, and I expect CCA as well, the arch code that knows that
> PCI/TSM functionality is available and can register a device, may be
> running too early to attach a driver to that device.
>
> I.e. I would like to just use faux_device, but without the ability to do
> EPROBE_DEFER, for example to await the plaform IOMMU driver. It needs to
> move to its own bus so the attach event can be handled at a better time.
>
One of the issues I’ve run into after switching to the faux_device model
is determining how to automatically load the guest and host TSM drivers
based on the availability of the device assignment feature.
The platform device previously provided a clean abstraction for this
behavior, which made autoloading straightforward
>
>> Otherwise the tsm core should accept NULL as the parent pointer during
>> registration, it probably already does..
>
> Yes, NULL @parent "just works" with tsm_register().
>
> However, I expect all tsm_register() callers to be from modular drivers.
-aneesh
On Thu, 31 Jul 2025 09:11:33 -0300
Jason Gunthorpe <jgg@ziepe.ca> wrote:
> On Wed, Jul 30, 2025 at 11:38:27AM +0100, Jonathan Cameron wrote:
> > On Wed, 30 Jul 2025 14:12:26 +0530
> > "Aneesh Kumar K.V" <aneesh.kumar@kernel.org> wrote:
> >
> > > Jason Gunthorpe <jgg@ziepe.ca> writes:
> > >
> > > > On Tue, Jul 29, 2025 at 06:10:45PM +0100, Jonathan Cameron wrote:
> > > >
> > > >> > +static struct platform_device cca_host_dev = {
> > > >> Hmm. Greg is getting increasingly (and correctly in my view) grumpy with
> > > >> platform devices being registered with no underlying resources etc as glue
> > > >> layers. Maybe some of that will come later.
> > > >
> > > > Is faux_device a better choice? I admit to not knowing entirely what
> > > > it is for..
> >
> > I'll go with a cautious yes to faux_device. This case of a glue device
> > with no resources and no reason to be on a particular bus was definitely
> > the intent but I'm not 100% sure without trying it that we don't run
> > into any problems.
> >
> > Not that many examples yet, but cpuidle-psci.c looks like a vaguely similar
> > case to this one.
> >
> > All it really does is move the location of the device and
> > smash together the device registration with probe/remove.
> > That means the device disappears if probe() fails, which is cleaner
> > in many ways than leaving a pointless stub behind.
> >
> > Maybe it isn't appropriate it if is actually useful to rmmod/modprobe the
> > driver.
>
> Yeah, exactly. Can a TSM driver even be modular? If it has to be built
> in then there is no reason to do this:
>
> > > The goal is to have tsm class device to be parented by the platform
> > > device.
>
> IMHO the only real point of that is to trigger module autoloading.
>
> Otherwise the tsm core should accept NULL as the parent pointer during
> registration, it probably already does..
If you mean create a class device with no parent, that's also something
we are slowly trying to fix. Reminds me that fixing up more perf devices
is still on my todo list.
Should be a child of something, so maybe that is a good reason for a
faux_device here if there is nothing else to use.
Jonathan
>
> Jason
On Thu, Jul 31, 2025 at 02:22:50PM +0100, Jonathan Cameron wrote: > If you mean create a class device with no parent, that's also something > we are slowly trying to fix. Reminds me that fixing up more perf devices > is still on my todo list. IIRC if you create a class device with no parent it gets placed on the virtual bus... Do you mean we should not do that? > Should be a child of something, so maybe that is a good reason for a > faux_device here if there is nothing else to use. Don't see such a big difference to have it be the child of a faux device on the faux bus than to just be directly on the virtual bus? Jason
On Thu, Jul 31, 2025 at 01:46:03PM -0300, Jason Gunthorpe wrote: > On Thu, Jul 31, 2025 at 02:22:50PM +0100, Jonathan Cameron wrote: > > > If you mean create a class device with no parent, that's also something > > we are slowly trying to fix. Reminds me that fixing up more perf devices > > is still on my todo list. > > IIRC if you create a class device with no parent it gets placed on the > virtual bus... > > Do you mean we should not do that? > > > Should be a child of something, so maybe that is a good reason for a > > faux_device here if there is nothing else to use. > > Don't see such a big difference to have it be the child of a faux > device on the faux bus than to just be directly on the virtual bus? Either is fine, but just never use a platform device for a non-platform-resource-backed device please. thanks, greg k-h
On Wed, 30 Jul 2025 11:38:27 +0100
Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:
> On Wed, 30 Jul 2025 14:12:26 +0530
> "Aneesh Kumar K.V" <aneesh.kumar@kernel.org> wrote:
>
> > Jason Gunthorpe <jgg@ziepe.ca> writes:
> >
> > > On Tue, Jul 29, 2025 at 06:10:45PM +0100, Jonathan Cameron wrote:
> > >
> > >> > +static struct platform_device cca_host_dev = {
> > >> Hmm. Greg is getting increasingly (and correctly in my view) grumpy with
> > >> platform devices being registered with no underlying resources etc as glue
> > >> layers. Maybe some of that will come later.
> > >
> > > Is faux_device a better choice? I admit to not knowing entirely what
> > > it is for..
>
> I'll go with a cautious yes to faux_device. This case of a glue device
> with no resources and no reason to be on a particular bus was definitely
> the intent but I'm not 100% sure without trying it that we don't run
> into any problems.
>
> Not that many examples yet, but cpuidle-psci.c looks like a vaguely similar
> case to this one.
>
> All it really does is move the location of the device and
> smash together the device registration with probe/remove.
> That means the device disappears if probe() fails, which is cleaner
> in many ways than leaving a pointless stub behind.
>
> Maybe it isn't appropriate it if is actually useful to rmmod/modprobe the
> driver.
>
> +CC Greg on basis I may have wrong end of the stick ;)
This time with at least one less typo in Greg's email address.
>
> > >
> > > But alternatively, why do we need a dummy "hw" struct device at all?
> > > Typically a subsystem like TSM should be structured to create its own
> > > struct devices..
> > >
> > > I would expect this to just call 'register tsm' ?
> > >
> >
> > The goal is to have tsm class device to be parented by the platform
> > device.
>
> >
> > # ls -al
> > total 0
> > drwxr-xr-x 2 root root 0 Jan 13 06:07 .
> > drwxr-xr-x 23 root root 0 Jan 1 00:00 ..
> > lrwxrwxrwx 1 root root 0 Jan 13 06:07 tsm0 -> ../../devices/platform/arm-rmi-dev/tsm/tsm0
> > # pwd
> > /sys/class/tsm
> >
> > -aneesh
> >
>
>
On Wed, Jul 30, 2025 at 01:23:33PM +0100, Jonathan Cameron wrote:
> On Wed, 30 Jul 2025 11:38:27 +0100
> Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:
>
> > On Wed, 30 Jul 2025 14:12:26 +0530
> > "Aneesh Kumar K.V" <aneesh.kumar@kernel.org> wrote:
> >
> > > Jason Gunthorpe <jgg@ziepe.ca> writes:
> > >
> > > > On Tue, Jul 29, 2025 at 06:10:45PM +0100, Jonathan Cameron wrote:
> > > >
> > > >> > +static struct platform_device cca_host_dev = {
> > > >> Hmm. Greg is getting increasingly (and correctly in my view) grumpy with
> > > >> platform devices being registered with no underlying resources etc as glue
> > > >> layers. Maybe some of that will come later.
> > > >
> > > > Is faux_device a better choice? I admit to not knowing entirely what
> > > > it is for..
> >
> > I'll go with a cautious yes to faux_device. This case of a glue device
> > with no resources and no reason to be on a particular bus was definitely
> > the intent but I'm not 100% sure without trying it that we don't run
> > into any problems.
> >
> > Not that many examples yet, but cpuidle-psci.c looks like a vaguely similar
> > case to this one.
> >
> > All it really does is move the location of the device and
> > smash together the device registration with probe/remove.
> > That means the device disappears if probe() fails, which is cleaner
> > in many ways than leaving a pointless stub behind.
> >
> > Maybe it isn't appropriate it if is actually useful to rmmod/modprobe the
> > driver.
> >
> > +CC Greg on basis I may have wrong end of the stick ;)
> This time with at least one less typo in Greg's email address.
Yes, use faux_device if you need/want a struct device to represent
something in the tree and it does NOT have any real platform resources
behind it. That's explicitly what it was designed for.
thanks,
greg k-h
Hi,
On 7/30/25 8:07 AM, Greg KH wrote:
> On Wed, Jul 30, 2025 at 01:23:33PM +0100, Jonathan Cameron wrote:
>> On Wed, 30 Jul 2025 11:38:27 +0100
>> Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:
>>
>>> On Wed, 30 Jul 2025 14:12:26 +0530
>>> "Aneesh Kumar K.V" <aneesh.kumar@kernel.org> wrote:
>>>
>>>> Jason Gunthorpe <jgg@ziepe.ca> writes:
>>>>
>>>>> On Tue, Jul 29, 2025 at 06:10:45PM +0100, Jonathan Cameron wrote:
>>>>>
>>>>>>> +static struct platform_device cca_host_dev = {
>>>>>> Hmm. Greg is getting increasingly (and correctly in my view) grumpy with
>>>>>> platform devices being registered with no underlying resources etc as glue
>>>>>> layers. Maybe some of that will come later.
>>>>>
>>>>> Is faux_device a better choice? I admit to not knowing entirely what
>>>>> it is for..
>>>
>>> I'll go with a cautious yes to faux_device. This case of a glue device
>>> with no resources and no reason to be on a particular bus was definitely
>>> the intent but I'm not 100% sure without trying it that we don't run
>>> into any problems.
>>>
>>> Not that many examples yet, but cpuidle-psci.c looks like a vaguely similar
>>> case to this one.
>>>
>>> All it really does is move the location of the device and
>>> smash together the device registration with probe/remove.
>>> That means the device disappears if probe() fails, which is cleaner
>>> in many ways than leaving a pointless stub behind.
>>>
>>> Maybe it isn't appropriate it if is actually useful to rmmod/modprobe the
>>> driver.
>>>
>>> +CC Greg on basis I may have wrong end of the stick ;)
>> This time with at least one less typo in Greg's email address.
>
> Yes, use faux_device if you need/want a struct device to represent
> something in the tree and it does NOT have any real platform resources
> behind it. That's explicitly what it was designed for.
Right, but this code is intended to trigger the kmod/userspace module
loader.
AFAIK, the faux device is currently missing a faux_device_id in
mod_devicetable, alias matching logic in file2alias, and probably a few
other things which keeps it from performing this function.
thanks,
On Fri, Oct 10, 2025 at 07:10:58AM -0500, Jeremy Linton wrote:
> > Yes, use faux_device if you need/want a struct device to represent
> > something in the tree and it does NOT have any real platform resources
> > behind it. That's explicitly what it was designed for.
>
> Right, but this code is intended to trigger the kmod/userspace module
> loader.
Faux devices are not intended to be bound, it says so right on the label:
* A "simple" faux bus that allows devices to be created and added
* automatically to it. This is to be used whenever you need to create a
* device that is not associated with any "real" system resources, and do
* not want to have to deal with a bus/driver binding logic. It is
^^^^^^^^^^^^^^^^^^^^^^^^^^
* intended to be very simple, with only a create and a destroy function
* available.
auxiliary_device is quite similar to faux except it is intended to be
bound to drivers, supports module autoloading and so on.
What you have here is the platform firmware provides the ARM SMC
(Secure Monitor Call Calling Convention) interface which is a generic
function call multiplexer between the OS and ARM firmware.
Then we have things like the TSM subsystem that want to load a driver
to use calls over SMC if the underlying platform firmware supports the
RSI group of SMC APIs. You'd have a TSM subsystem driver that uses the
RSI call group over SMC that autobinds when the RSI call group is
detected when the SMC is first discovered.
So you could use auxiliary_device, you'd consider SMC itself to be the
shared HW block and all the auxiliary drivers are per-subsystem
aspects of that shared SMC interface. It is not a terrible fit for
what it was intended for at least.
Jason
Hi, On 10/10/25 8:59 AM, Jason Gunthorpe wrote: > On Fri, Oct 10, 2025 at 07:10:58AM -0500, Jeremy Linton wrote: >>> Yes, use faux_device if you need/want a struct device to represent >>> something in the tree and it does NOT have any real platform resources >>> behind it. That's explicitly what it was designed for. >> >> Right, but this code is intended to trigger the kmod/userspace module >> loader. > > Faux devices are not intended to be bound, it says so right on the label: > > * A "simple" faux bus that allows devices to be created and added > * automatically to it. This is to be used whenever you need to create a > * device that is not associated with any "real" system resources, and do > * not want to have to deal with a bus/driver binding logic. It is > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > * intended to be very simple, with only a create and a destroy function > * available. > > auxiliary_device is quite similar to faux except it is intended to be > bound to drivers, supports module autoloading and so on. > > What you have here is the platform firmware provides the ARM SMC > (Secure Monitor Call Calling Convention) interface which is a generic > function call multiplexer between the OS and ARM firmware. > > Then we have things like the TSM subsystem that want to load a driver > to use calls over SMC if the underlying platform firmware supports the > RSI group of SMC APIs. You'd have a TSM subsystem driver that uses the > RSI call group over SMC that autobinds when the RSI call group is > detected when the SMC is first discovered. > > So you could use auxiliary_device, you'd consider SMC itself to be the > shared HW block and all the auxiliary drivers are per-subsystem > aspects of that shared SMC interface. It is not a terrible fit for > what it was intended for at least. Turns out that changing any of this, will at the moment break systemd's confidential vm detection, because they wanted the earliest indicator the guest was capable and that turned out to be this platform device.
On Fri, Oct 10, 2025 at 10:28:36AM -0500, Jeremy Linton wrote: > > So you could use auxiliary_device, you'd consider SMC itself to be the > > shared HW block and all the auxiliary drivers are per-subsystem > > aspects of that shared SMC interface. It is not a terrible fit for > > what it was intended for at least. > > Turns out that changing any of this, will at the moment break systemd's > confidential vm detection, because they wanted the earliest indicator the > guest was capable and that turned out to be this platform device. Having systemd detect a software created platform device sounds compltely crazy, don't do that. Make a proper sysfs uapi for such a general idea please. Jason
On 10/10/25 10:30 AM, Jason Gunthorpe wrote: > On Fri, Oct 10, 2025 at 10:28:36AM -0500, Jeremy Linton wrote: > >>> So you could use auxiliary_device, you'd consider SMC itself to be the >>> shared HW block and all the auxiliary drivers are per-subsystem >>> aspects of that shared SMC interface. It is not a terrible fit for >>> what it was intended for at least. >> >> Turns out that changing any of this, will at the moment break systemd's >> confidential vm detection, because they wanted the earliest indicator the >> guest was capable and that turned out to be this platform device. > > Having systemd detect a software created platform device sounds > compltely crazy, don't do that. Make a proper sysfs uapi for such a > general idea please. Yes, I agree, its just at the time the statment was around what is the most reliable early indicator, and since there isn't a hwcap or anything that ended up being the choice, as disgusting as it is. Presumably once all this works out the sysfs/api surface will be more 'defined' > > Jason
Jeremy Linton wrote: > On 10/10/25 10:30 AM, Jason Gunthorpe wrote: > > On Fri, Oct 10, 2025 at 10:28:36AM -0500, Jeremy Linton wrote: > > > >>> So you could use auxiliary_device, you'd consider SMC itself to be the > >>> shared HW block and all the auxiliary drivers are per-subsystem > >>> aspects of that shared SMC interface. It is not a terrible fit for > >>> what it was intended for at least. > >> > >> Turns out that changing any of this, will at the moment break systemd's > >> confidential vm detection, because they wanted the earliest indicator the > >> guest was capable and that turned out to be this platform device. > > > > Having systemd detect a software created platform device sounds > > compltely crazy, don't do that. Make a proper sysfs uapi for such a > > general idea please. > > Yes, I agree, its just at the time the statment was around what is the > most reliable early indicator, and since there isn't a hwcap or anything > that ended up being the choice, as disgusting as it is. > > Presumably once all this works out the sysfs/api surface will be more > 'defined' It has definition today. All guest-side TSM drivers currently call tsm_report_register(), that establishes /sys/kernel/config/tsm/report which is the common cross-arch transport for retrieving CVM launch attestation reports. In the TEE I/O patches [1] a /sys/class/tsm/tsmX device will be created by all platforms that support TEE I/O. However, systemd would need to be careful to differentiate host-side TSMs vs guest-side, and that is only possible when the TSM supports TEE I/O. I would be open to adding a simple attribute to that class device for this common "am I a CVM" question for systemd. Would just need to update all the CVM guest drivers to register that class device in the non TEE I/O case. [1]: http://lore.kernel.org/20250911235647.3248419-2-dan.j.williams@intel.com
On Fri, Oct 10, 2025 at 11:44:04AM -0700, dan.j.williams@intel.com wrote: > Jeremy Linton wrote: > > On 10/10/25 10:30 AM, Jason Gunthorpe wrote: > > > On Fri, Oct 10, 2025 at 10:28:36AM -0500, Jeremy Linton wrote: > > > > > >>> So you could use auxiliary_device, you'd consider SMC itself to be the > > >>> shared HW block and all the auxiliary drivers are per-subsystem > > >>> aspects of that shared SMC interface. It is not a terrible fit for > > >>> what it was intended for at least. > > >> > > >> Turns out that changing any of this, will at the moment break systemd's > > >> confidential vm detection, because they wanted the earliest indicator the > > >> guest was capable and that turned out to be this platform device. > > > > > > Having systemd detect a software created platform device sounds > > > compltely crazy, don't do that. Make a proper sysfs uapi for such a > > > general idea please. > > > > Yes, I agree, its just at the time the statment was around what is the > > most reliable early indicator, and since there isn't a hwcap or anything > > that ended up being the choice, as disgusting as it is. > > > > Presumably once all this works out the sysfs/api surface will be more > > 'defined' > > It has definition today. > > All guest-side TSM drivers currently call tsm_report_register(), that > establishes /sys/kernel/config/tsm/report which is the common cross-arch > transport for retrieving CVM launch attestation reports. I suspect this ins't a TSM question but an existing question if any of the underlying CC frameworks are enabled. It is this stuff: https://github.com/systemd/systemd/blob/main/src/basic/confidential-virt.c https://github.com/systemd/systemd/commit/2572bf6a39b6c548acef07fd25f461c5a88560af Like the s390 detection logic, the sysfs path being checked is not labeled as ABI, and may change in the future. It was chosen because its directly tied to the kernel's detection of the realm service interface rather to the Trusted Security Module (TSM) which is what is being triggered by the device entry. Maybe a /sys/firmware/smc/rsi file might be appropriate? Given how small a deployed fooprint ARM CCA has right now (ie none) it would be good to fix this ASAP so it doesn't become entrenched. Jason
Hi, On 10/10/25 5:34 PM, Jason Gunthorpe wrote: > On Fri, Oct 10, 2025 at 11:44:04AM -0700, dan.j.williams@intel.com wrote: >> Jeremy Linton wrote: >>> On 10/10/25 10:30 AM, Jason Gunthorpe wrote: >>>> On Fri, Oct 10, 2025 at 10:28:36AM -0500, Jeremy Linton wrote: >>>> >>>>>> So you could use auxiliary_device, you'd consider SMC itself to be the >>>>>> shared HW block and all the auxiliary drivers are per-subsystem >>>>>> aspects of that shared SMC interface. It is not a terrible fit for >>>>>> what it was intended for at least. >>>>> >>>>> Turns out that changing any of this, will at the moment break systemd's >>>>> confidential vm detection, because they wanted the earliest indicator the >>>>> guest was capable and that turned out to be this platform device. >>>> >>>> Having systemd detect a software created platform device sounds >>>> compltely crazy, don't do that. Make a proper sysfs uapi for such a >>>> general idea please. >>> >>> Yes, I agree, its just at the time the statment was around what is the >>> most reliable early indicator, and since there isn't a hwcap or anything >>> that ended up being the choice, as disgusting as it is. >>> >>> Presumably once all this works out the sysfs/api surface will be more >>> 'defined' >> >> It has definition today. >> >> All guest-side TSM drivers currently call tsm_report_register(), that >> establishes /sys/kernel/config/tsm/report which is the common cross-arch >> transport for retrieving CVM launch attestation reports. > > I suspect this ins't a TSM question but an existing question if any of > the underlying CC frameworks are enabled. > > It is this stuff: > > https://github.com/systemd/systemd/blob/main/src/basic/confidential-virt.c > https://github.com/systemd/systemd/commit/2572bf6a39b6c548acef07fd25f461c5a88560af > > Like the s390 detection logic, the sysfs path being checked is not labeled > as ABI, and may change in the future. It was chosen because its > directly tied to the kernel's detection of the realm service interface > rather to the Trusted Security Module (TSM) which is what is being > triggered by the device entry. > > Maybe a /sys/firmware/smc/rsi file might be appropriate? Except that you can see from the code that this problem is being solved in a hw platform dependent way for 4+ platforms now. Ideally the sysfs node would be common across all those hw platforms and reflect the vm capabilities so the code doesn't' need #ifdef's. Meaning it shouldn't have the smc/rsi arm'ism in the name, and maybe shouldn't be in /sys/firmware Thanks, > > Given how small a deployed fooprint ARM CCA has right now (ie none) it > would be good to fix this ASAP so it doesn't become entrenched. > > Jason
On Fri, Oct 10, 2025 at 12:30:46PM -0300, Jason Gunthorpe wrote: > On Fri, Oct 10, 2025 at 10:28:36AM -0500, Jeremy Linton wrote: > > > > So you could use auxiliary_device, you'd consider SMC itself to be the > > > shared HW block and all the auxiliary drivers are per-subsystem > > > aspects of that shared SMC interface. It is not a terrible fit for > > > what it was intended for at least. > > > > Turns out that changing any of this, will at the moment break systemd's > > confidential vm detection, because they wanted the earliest indicator the > > guest was capable and that turned out to be this platform device. > > Having systemd detect a software created platform device sounds > compltely crazy, don't do that. Make a proper sysfs uapi for such a > general idea please. Agreed. Please do NOT abuse platform devices for this, as this is NOT a platform device. It is a random virtual device that you are wanting to create out of thin air based on something else. Trigger off of that "something else" please. thanks, greg k-h
On Fri, Oct 10, 2025 at 07:10:58AM -0500, Jeremy Linton wrote:
> Hi,
>
>
> On 7/30/25 8:07 AM, Greg KH wrote:
> > On Wed, Jul 30, 2025 at 01:23:33PM +0100, Jonathan Cameron wrote:
> > > On Wed, 30 Jul 2025 11:38:27 +0100
> > > Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:
> > >
> > > > On Wed, 30 Jul 2025 14:12:26 +0530
> > > > "Aneesh Kumar K.V" <aneesh.kumar@kernel.org> wrote:
> > > >
> > > > > Jason Gunthorpe <jgg@ziepe.ca> writes:
> > > > > > On Tue, Jul 29, 2025 at 06:10:45PM +0100, Jonathan Cameron wrote:
> > > > > > > > +static struct platform_device cca_host_dev = {
> > > > > > > Hmm. Greg is getting increasingly (and correctly in my view) grumpy with
> > > > > > > platform devices being registered with no underlying resources etc as glue
> > > > > > > layers. Maybe some of that will come later.
> > > > > >
> > > > > > Is faux_device a better choice? I admit to not knowing entirely what
> > > > > > it is for..
> > > >
> > > > I'll go with a cautious yes to faux_device. This case of a glue device
> > > > with no resources and no reason to be on a particular bus was definitely
> > > > the intent but I'm not 100% sure without trying it that we don't run
> > > > into any problems.
> > > >
> > > > Not that many examples yet, but cpuidle-psci.c looks like a vaguely similar
> > > > case to this one.
> > > >
> > > > All it really does is move the location of the device and
> > > > smash together the device registration with probe/remove.
> > > > That means the device disappears if probe() fails, which is cleaner
> > > > in many ways than leaving a pointless stub behind.
> > > >
> > > > Maybe it isn't appropriate it if is actually useful to rmmod/modprobe the
> > > > driver.
> > > >
> > > > +CC Greg on basis I may have wrong end of the stick ;)
> > > This time with at least one less typo in Greg's email address.
> >
> > Yes, use faux_device if you need/want a struct device to represent
> > something in the tree and it does NOT have any real platform resources
> > behind it. That's explicitly what it was designed for.
>
> Right, but this code is intended to trigger the kmod/userspace module
> loader.
Why?
> AFAIK, the faux device is currently missing a faux_device_id in
> mod_devicetable, alias matching logic in file2alias, and probably a few
> other things which keeps it from performing this function.
How would a faux device ever expect to get auto-loaded? That's not what
is supposed to be happening here at all.
If you have real hardware backing something, then use the real driver
type. that is NOT a faux driver, which is, as the name says, for "fake"
devices that you wish to add to the device/driver tree.
thanks,
greg k-h
Hi,
On 10/10/25 7:38 AM, Greg KH wrote:
> On Fri, Oct 10, 2025 at 07:10:58AM -0500, Jeremy Linton wrote:
>> Hi,
>>
>>
>> On 7/30/25 8:07 AM, Greg KH wrote:
>>> On Wed, Jul 30, 2025 at 01:23:33PM +0100, Jonathan Cameron wrote:
>>>> On Wed, 30 Jul 2025 11:38:27 +0100
>>>> Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:
>>>>
>>>>> On Wed, 30 Jul 2025 14:12:26 +0530
>>>>> "Aneesh Kumar K.V" <aneesh.kumar@kernel.org> wrote:
>>>>>
>>>>>> Jason Gunthorpe <jgg@ziepe.ca> writes:
>>>>>>> On Tue, Jul 29, 2025 at 06:10:45PM +0100, Jonathan Cameron wrote:
>>>>>>>>> +static struct platform_device cca_host_dev = {
>>>>>>>> Hmm. Greg is getting increasingly (and correctly in my view) grumpy with
>>>>>>>> platform devices being registered with no underlying resources etc as glue
>>>>>>>> layers. Maybe some of that will come later.
>>>>>>>
>>>>>>> Is faux_device a better choice? I admit to not knowing entirely what
>>>>>>> it is for..
>>>>>
>>>>> I'll go with a cautious yes to faux_device. This case of a glue device
>>>>> with no resources and no reason to be on a particular bus was definitely
>>>>> the intent but I'm not 100% sure without trying it that we don't run
>>>>> into any problems.
>>>>>
>>>>> Not that many examples yet, but cpuidle-psci.c looks like a vaguely similar
>>>>> case to this one.
>>>>>
>>>>> All it really does is move the location of the device and
>>>>> smash together the device registration with probe/remove.
>>>>> That means the device disappears if probe() fails, which is cleaner
>>>>> in many ways than leaving a pointless stub behind.
>>>>>
>>>>> Maybe it isn't appropriate it if is actually useful to rmmod/modprobe the
>>>>> driver.
>>>>>
>>>>> +CC Greg on basis I may have wrong end of the stick ;)
>>>> This time with at least one less typo in Greg's email address.
>>>
>>> Yes, use faux_device if you need/want a struct device to represent
>>> something in the tree and it does NOT have any real platform resources
>>> behind it. That's explicitly what it was designed for.
>>
>> Right, but this code is intended to trigger the kmod/userspace module
>> loader.
>
> Why?
Originally it was because without the tsm drivers loaded there wasn't
any way for a CCA guest to know it is running in a confidential compute
environment. That is a bit of a problem for generic distro kernels which
don't want to load a bunch of functionality on devices that don't
support it. So, this triggers the tsm module load, which in turn
provides enough metadata for userspace to start attestation/whatever it
needs. (Ex: systemd-detect-virt --cvm).
I think Jason clarifies whats going on too.
>
>> AFAIK, the faux device is currently missing a faux_device_id in
>> mod_devicetable, alias matching logic in file2alias, and probably a few
>> other things which keeps it from performing this function.
>
> How would a faux device ever expect to get auto-loaded? That's not what
> is supposed to be happening here at all.
>
> If you have real hardware backing something, then use the real driver
> type. that is NOT a faux driver, which is, as the name says, for "fake"
> devices that you wish to add to the device/driver tree.
>
> thanks,
>
> greg k-h
© 2016 - 2026 Red Hat, Inc.