From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web09.4655.1618480302072552788 for ; Thu, 15 Apr 2021 02:51:43 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Q7Jsllyp; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1618480301; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=a3lVfu2JWcnIRFkhDIBMD/sjq9r6OL0/Ic5RD6uLexg=; b=Q7JsllypzVJP//p5+SHE0vxcPtT0VmO+ecE3+Ex7zAitU7XHjLInrdYkxwOztq2UUxVRhJ EaH7Aro4YEwNQjSdmMOwW82M7SI9j9px64/RmBG0nFCuE3bbjUxYUGdydD7Lqe7iUY+EBS P7JFCz8gWahSQmivBR25/7SGu17HEsc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-509-CnlnKaEUM6iNxBeuW56hGQ-1; Thu, 15 Apr 2021 05:51:39 -0400 X-MC-Unique: CnlnKaEUM6iNxBeuW56hGQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1ADED8030A1; Thu, 15 Apr 2021 09:51:38 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-115-85.ams2.redhat.com [10.36.115.85]) by smtp.corp.redhat.com (Postfix) with ESMTP id 53A7810023B0; Thu, 15 Apr 2021 09:51:32 +0000 (UTC) Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021) To: Ethin Probst , Andrew Fish Cc: Mike Kinney , "devel@edk2.groups.io" , Leif Lindholm , "Desimone, Nathaniel L" , Rafael Rodrigues Machado , Gerd Hoffmann References: <2379DE31-D6E1-491E-AE22-416085D73765@intel.com> <66e073bb-366b-0559-4a78-fc5e8215aca1@redhat.com> <16758FB6436B1195.32393@groups.io> From: "Laszlo Ersek" Message-ID: <6b973fc0-e6ee-bca0-ab65-94a0a57633d3@redhat.com> Date: Thu, 15 Apr 2021 11:51:32 +0200 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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