Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

["Laszlo Ersek" <lersek@redhat.com>]

On 04/15/21 06:01, Ethin Probst wrote:
> Hi Mike and Andrew,
> 
> Thanks for your responses. I'm looking at the VirtIO block device now
> but will certainly have a look at the others as well. We'll also need
> to define a completely new protocol for audio, as well, as no existing
> protocol will fit the bill. The generic protocol proposed by Andrew
> might work, though I was thinking of a couple modifications: primarily
> that the audio interface will most likely be asynchronous in nature.

EFI_SIMPLE_NETWORK_PROTOCOL is a good design for a request queueing API.
(One limitation that I could mention here is that it does not permit the
queueing of the exact same buffer (= bus adress) multiple times at the
same time, but that's not a grave limitation in practice.) For audio
output inspiration, you could excise the "admin" type member functions,
just focus on the queueing (also ignore Rx, only focus on Tx).

And then I suggest reading "OvmfPkg/VirtioNetDxe/TechNotes.txt", which
explains how EFI_SIMPLE_NETWORK_PROTOCOL is implemented for virtio-net.
It's the most complex of the virtio drivers in OvmfPkg (regarding virtio
exchanges), exactly because it needs to deal with bidirectional async
transfer. You can ignore the Rx direction and just look at Tx.

VirtioLib contains several utility functions. A subset of those
functions is only useful to the simpler (synchronous) virtio drivers,
such as virtio-blk, virtio-scsi, ..., that implement request-response
patterns. Because virtio-net is asynchronous (it does real queueing,
down from the EFI protocol interface), some of the request-response
helper functions in VirtioLib do not apply.

virtio-net is still used with polling; what's important to know is that
it's not the driver itself that performs the repeated checking. The SNP
protocol specifies three members that relate to polling; in all three
cases, the polling is driven from outside of the driver.

Tx polling is performed via EFI_SIMPLE_NETWORK.GetStatus(), it is called
repeatedly by whatever agent is using SNP.

Rx polling is performed either via EFI_SIMPLE_NETWORK.Receive() (called
repeatedly by whatever agent is using SNP), or via the "WaitForPacket"
event. The latter is still polling, only the loop is iternal the
WaitForEvent() boot service. Anyway, Rx should be OK to ignore for now.

Thanks
Laszlo