> > > - Create drivers/virt/coco/tdx-tsm/bus.c for registering the tdx_subsys.
> > > The tdx_subsys has sysfs attributes like "version" (host and guest
> > > need this, but have different calls to get at the information) and
> > > "firmware" (only host needs that). So the common code will take sysfs
> > > groups passed as a parameter.
> > >
> > > - The "tdx_tsm" device which is unused in this patch set can be
> >
> > It is used in this patch, Chao creates tdx module 'version' attr on this
> > device. But I assume you have different opinion: tdx_subsys represents
> > the whole tdx_module and should have the 'version', and tdx_tsm is a
> > sub device dedicate for TDX Connect, is it?
>
> The main reason for a tdx_tsm device in addition to the subsys is to
> allow for deferred attachment.
I've found another reason, to dynamic control tdx tsm's lifecycle.
tdx_tsm driver uses seamcalls so its functionality relies on tdx module
initialization & vmxon. The former is a one way path but vmxon can be
dynamic off by KVM. vmxoff is fatal to tdx_tsm driver especially on some
can-not-fail destroy path.
So my idea is to remove tdx_tsm device (thus disables tdx_tsm driver) on
vmxoff.
KVM TDX core TDX TSM driver
-----------------------------------------------------
tdx_disable()
tdx_tsm dev del
driver.remove()
vmxoff()
An alternative is to move vmxon/off management out of KVM, that requires
a lot of complex work IMHO, Chao & I both prefer not to touch it.
That said, we still want to "deal with bus/driver binding logic" so faux
is not a good fit.
>
> Now, that said, the faux_device infrastructure has arrived since this
> all started and *could* replace tdx_subsys. The only concern is whether
> the tdx_tsm driver ever needs to do probe deferral to wait for IOMMU or
> PCI initialization to happen first.
The tdx_tsm driver needs to wait for IOMMU/PCI initialization...
>
> If probe deferral is needed that requires a bus, if probe can always be
> synchronous with TDX module init then faux_device could work.
... but doesn't see need for TDX Module early init now. Again TDX Module
init requires vmxon, so it can't be earlier than KVM init, nor the
IOMMU/PCI init. So probe synchronous with TDX module init should be OK.
But considering the tdx tsm's lifecycle concern, I still don't prefer
faux.
Thanks,
Yilun
