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

[Andrew Fish via groups.io]

> On Apr 15, 2021, at 2:51 AM, Laszlo Ersek <lersek at redhat.com> wrote:
> 
> 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.
> 

Laszlo,

In the audio case I think the driver can do its own polling so we don’t need to copy the networking stack from that point of view, but as you point out it is a good example of the VirtIo magic. 

Also thanks for the more detailed pointers. 

Thanks,

Andrew Fish

> Thanks
> Laszlo
> 
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#74133): https://edk2.groups.io/g/devel/message/74133
Mute This Topic: https://groups.io/mt/81710286/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-