On Fri, 2026-09-04 at 09:12 +0900, Damien Le Moal wrote: > On 9/3/26 20:51, Manivannan Sadhasivam wrote: > > 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. > > There is nothing inherently racy about the config space. It is about > the fact > that most PCI endpoint controllers: > 1) Do not raise an interrupt when PCI BARs or config space is written > by the > host RC, and > 2) All PCI endpoint controllers that Linux supports do not allow > drivers to > create extended capabilities in the config space that can then be > emulated in > the endpoint driver (enabling that would require 1 to be supported, > obviously). > > (2) can be delt with quirks. Not great, but simple enough. And in > this case, we > need it more because of the virtio-pci specs, which are not great to > start with. > > And for (1), the only real problem that causes is that an endpoint > driver needs > to poll PCI BARs/submission queues to see if the host issued > commands. Again not > great, but that works just fine. Alistair's point about burning a CPU > doing that > is simply so that we can reduce command latency and get good enough > performance.
It is actually racy. If we don't burn a CPU to check we end up racing, with the host as we are too slow to update the config space. > > We went through all of that already with the NVMe PCI endpoint. Works > well > enough and does what is intended, which is the same here for the > virtio-scsi > endpoint driver: create a platform where one can emulate a SCSI > device to > experiment with new features etc. This is all intended as a > development/test > tool, not for production use. > > I do not know virtio-msg. First time I hear about it. And I am not > sure if there > is a standard way of exposing a SCSI host through that. virtio-msg-amp does seem promising. I'll dig into it a bit more and keep an eye on it. As virtio-msg-amp is very new though, I'm not sure it solves the problem right now. Alistair
