[svsm-devel] Using a linux bus for SVSM devices

James Bottomley James.Bottomley at HansenPartnership.com
Tue Feb 25 20:27:30 CET 2025


It looks like I'm not going to make the next SVSM meeting, so here is a
brain dump on how the linux bus type for virtio works.  Basically it's
a capsule for matching (and automatically finding driver modules) for
discovered devices.

The way we should use it is pretty much the same as virtio (see
drivers/virtio/virtio.c for the bus definitions).  There's also a nice
series of blog posts which documents this:

https://www.redhat.com/en/blog/virtio-devices-and-drivers-overview-headjack-and-phone
https://www.redhat.com/en/blog/virtqueues-and-virtio-ring-how-data-travels

The only real difference is the configuration signalling, which is done
over a pluggable configuration interface (which is either mmio, vdpa or
pci).  The SVSM only signals over the architectural mailbox API as
defined by the SVSM API Spec, so we don't need to bother with the
config_ops and can use a simple static C based API instead.

So I would say we copy virtio bus type, pretty much, with the standard
groups, match/probe/remove and uevent for driver binding and put it
under the drivers/virt/coco (or we could go with a new
drivers/virt/svsm).  Next we simply need a defined API for calling into
the SVSM (so something like the AMD abstraction which hides the calling
convention) which we define in a header instead of using config_ops. 
The body of the API would vary between architectures, so the
implementation would likely be in architecture specific code.

The only other question is what we do about device IDs.  I'm strongly
tempted simply to use strings, but all the other code does use fixed
length ids, so we could probably follow virtio_device_id except have a
single u32 for device_id (I've no idea what virtio uses vendor_id for
since every driver I've looked at leaves it as a wildcard).

The final thing would be to think about interrupts, but since the TPM
driver is strictly request/response, we can defer that until we know if
the observability driver will need them or not.

Regards,

James



More information about the Svsm-devel mailing list