From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from rn-mailsvcp-ppex-lapp35.apple.com (rn-mailsvcp-ppex-lapp35.apple.com [17.179.253.44]) by mx.groups.io with SMTP id smtpd.web09.9369.1618502512905245384 for ; Thu, 15 Apr 2021 09:01:52 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=HWQi+xTT; spf=pass (domain: apple.com, ip: 17.179.253.44, mailfrom: afish@apple.com) Received: from pps.filterd (rn-mailsvcp-ppex-lapp35.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp35.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 13FG1paO013305; Thu, 15 Apr 2021 09:01:52 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=9lScirj5looikVDXa12bgHiDeDX1V6dtGkUAnYAw0fM=; b=HWQi+xTTfgck1c0xCrN9TN0OLcZ6LoLi3ZafDI/1tD2/fJstLAf3qNKmg23wYMjhLj23 CzXeqQt06oYBFvTVv9nMXUPkvI5ofTFpSVjc3lrEHpc1DImTNTcvwgUMjyN+FeD1/lkp weRMX1UjDrxKSMuvSkGDHmGawQCvwjvyeyNQ7DtZMvsjPF3BrbOS49zZgIVUrWNbLJK8 4xxJEOQcc4MdVxHkT6HqoRvYrnSNbVXP0nCPsNZkeztZqtdMZo2xogXxerXe5lYhnUns D8/+kvCOX6cyQoLPKoh/9N0au6R3YiplebcihZNUIi3QbOtSQQJT6T4j5avYUz+cfbdX jQ== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by rn-mailsvcp-ppex-lapp35.rno.apple.com with ESMTP id 37u7j9qwmx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 15 Apr 2021 09:01:52 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPS id <0QRM00HR14J3H230@rn-mailsvcp-mta-lapp03.rno.apple.com>; Thu, 15 Apr 2021 09:01:51 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) id <0QRM00W004HUR300@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Thu, 15 Apr 2021 09:01:51 -0700 (PDT) X-Va-A: X-Va-T-CD: 076955f3becce2df77d006c843a15678 X-Va-E-CD: 4730c80ee67030d4f2c83e40b4ab0357 X-Va-R-CD: 6f0325faf294bd23a6d751c620be9d51 X-Va-CD: 0 X-Va-ID: b51b1a2f-d75f-4e84-a3cb-16e209bbbf81 X-V-A: X-V-T-CD: 076955f3becce2df77d006c843a15678 X-V-E-CD: 4730c80ee67030d4f2c83e40b4ab0357 X-V-R-CD: 6f0325faf294bd23a6d751c620be9d51 X-V-CD: 0 X-V-ID: a0c56f88-38e6-4122-a6fa-b4e009a65e03 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-04-15_06:2021-04-15,2021-04-15 signatures=0 Received: from [17.235.1.165] (unknown [17.235.1.165]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPSA id <0QRM007FX4J1BV00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Thu, 15 Apr 2021 09:01:51 -0700 (PDT) MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021) From: "Andrew Fish" In-reply-to: <6b973fc0-e6ee-bca0-ab65-94a0a57633d3@redhat.com> Date: Thu, 15 Apr 2021 09:01:49 -0700 Cc: Ethin Probst , Mike Kinney , Leif Lindholm , "Desimone, Nathaniel L" , Rafael Rodrigues Machado , Gerd Hoffmann Message-id: <23F97839-DCEC-41AE-AA2B-A1F55E0CBC49@apple.com> References: <2379DE31-D6E1-491E-AE22-416085D73765@intel.com> <66e073bb-366b-0559-4a78-fc5e8215aca1@redhat.com> <16758FB6436B1195.32393@groups.io> <6b973fc0-e6ee-bca0-ab65-94a0a57633d3@redhat.com> To: devel@edk2.groups.io, lersek@redhat.com X-Mailer: Apple Mail (2.3654.20.0.2.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-04-15_06:2021-04-15,2021-04-15 signatures=0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On Apr 15, 2021, at 2:51 AM, Laszlo Ersek wrote: >=20 > On 04/15/21 06:01, Ethin Probst wrote: >> Hi Mike and Andrew, >>=20 >> 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. >=20 > 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 (=3D 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). >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Tx polling is performed via EFI_SIMPLE_NETWORK.GetStatus(), it is called > repeatedly by whatever agent is using SNP. >=20 > 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. >=20 Laszlo, In the audio case I think the driver can do its own polling so we don=E2= =80=99t 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.=20 Also thanks for the more detailed pointers.=20 Thanks, Andrew Fish > Thanks > Laszlo >=20 >=20 >=20 >=20 >=20 >=20