Re: [PATCH 0/2] scsi: Initial commit of VirtIO PCIe Endpoint Driver

[Manivannan Sadhasivam]

On Tue, Sep 01, 2026 at 10:35:49AM +0200, Niklas Cassel wrote:
> On Tue, Sep 01, 2026 at 11:46:48AM +1000, alistair23@xxxxxxxxx wrote:
> > From: Alistair Francis <alistair.francis@xxxxxxx>
> > 
> > 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/cover.1781514628.git.bertrand.marquis@xxxxxxx

-- 
மணிவண்ணன் சதாசிவம்