On Tue, Sep 01, 2026 at 10:35:49AM +0200, Niklas Cassel wrote: > On Tue, Sep 01, 2026 at 11:46:48AM +1000, [email protected] wrote: > > From: Alistair Francis <[email protected]> > > > > This series adds a VirtIO SCSI endpoint built on top of the VirtIO PCIe > > endpoint. This is a similar approach to the NVMe PCIe Endpoint > > (drivers/nvme/target/pci-epf.c) but for SCSI. > > > > This does end up being somewhat similar to the pci-epf.c code, but > > re-written for SCSI. > > > > This approach allows a PCIe Endpoint device (tested on a > > radxa-rock5b) to setup what appears to be a SCSI device, using an > > existing SCSI backend (tested using scsi_debug). > > > > At this point a host can connect over PCIe, ensure virtio_pci and > > virtio_scsi is loaded and on PCIe rescan will see a scsi device. > > > > There are a few pain points with this approach though: > > 1. We have to use the Legacy SCSI VirtIO driver. This is because the > > Raxda Rock5b (and AFAIK all PCIe Endpoint hardware) can't add > > capabilities. So we can't advertise the VirtIO Common configuration > > capability, which means we can't be a modern VirtIO SCSI device. > > > > This is unfortunate, but there doesn't seem to be any way around > > this, at least with the current hardware. > > > > 1.2. Legacy virtio devices only have 32 feature bits and therefore can't > > set the VIRTIO_F_ACCESS_PLATFORM (bit 33) feature. This means the > > vring_use_map_api() function will return false. > > > > Currently Linux endpoint devices use the legacy virtio interface as > > they aren't able to advertise the Common configuration capability. > > As most PCI endpoint capable PCIe controllers do not allow modifying the > > capability list, and thus are unable to advertise the Common > > configuration > > capability. This means the device's inbound TLPs fault on the host > > SMMU because the vring descriptors carry raw physical addresses. > > > > This series adds a quirk that forces a subset of legacy virtio devices > > to use the DMA Map API (vring_use_map_api() will return true), > > which fixes this issue. > > > > It's unideal that we have to hard code a quirk to basically just > > advertise the VIRTIO_F_ACCESS_PLATFORM feature, but (see 1) as we > > are stuck with legacy virtio devices there isn't much else we can do. > > > > 2. We have to pin scsit_pci_epf_poll_cfg_thread() on a CPU in order to > > respond fast enough to the host. This means we effectivly burn a CPU > > to read and write some values. But as there are no intterupts > > generated on these events and we need to be very quick there isn't > > another option. > >
Most of these pain points will go away if you use virtio-msg [1] transport instead of the virtio-pci transport. Using the virtio-pci transport on a real PCIe device without a way to trap and emulate the config space requests will always be racy. - Mani [1] https://lore.kernel.org/virtio-comment/[email protected] -- மணிவண்ணன் சதாசிவம்
