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

[Damien Le Moal]

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