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

[Alistair Francis <Alistair.Francis@wdc.com>]

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