On 9/4/26 12:19, Alistair Francis wrote: >>> 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.
How come ? At least for nvme, it does not matter how slow the endpoint is to pull commands from the SQ: if the SQ becomes full, the host just stops submitting. There is no race. I would expect virtio-pci/scsi to have a similar race-safe protocol mechanism. If there is indeed a race, then we are talking about a deficiency of the protocols rather than the transport. -- Damien Le Moal Western Digital Research
