On Fri, 2026-09-04 at 13:41 +0900, Damien Le Moal wrote: > 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.
The issue is in the config space, setting up VirtIO-PCI. From memory the QueuePFN (which indicates the currently used page number of the queue) causes all sorts of issues if you don't zero it fast enough. Alistair
