From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=0.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 32819C433DB for ; Thu, 28 Jan 2021 15:43:34 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D653364DD9 for ; Thu, 28 Jan 2021 15:43:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D653364DD9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:39788 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l59SG-00024o-SU for qemu-devel@archiver.kernel.org; Thu, 28 Jan 2021 10:43:32 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38928) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l59PC-000861-Uh for qemu-devel@nongnu.org; Thu, 28 Jan 2021 10:40:23 -0500 Received: from mail-pf1-x42f.google.com ([2607:f8b0:4864:20::42f]:35073) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l59P6-0003NX-Tq for qemu-devel@nongnu.org; Thu, 28 Jan 2021 10:40:22 -0500 Received: by mail-pf1-x42f.google.com with SMTP id w14so4227043pfi.2 for ; Thu, 28 Jan 2021 07:40:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vhxSKjoSd1R7iDKXpsrK7l28NFZix7NigyHB90ikHtY=; b=qM+G4j8izzw0uGnIRWEc8tFpiimF8HN7PGsh/M/IW8VSxDpGpQlhGjimSV1cVaKiXL 8lf057xx4d3h3BTCiCw1BWmS91Me5ieZrLKCnNi+q0pplCpIOO6Vdrs8dJXEZf159oFp KD9gMTE3mAZujwQT7MsJhgLEF7bOZobxS8s8AmFnmnVX7/7AYkLiPO2nG+2NvUqyeF4L THmGA4ZXXOevgbicYanXWwH5MMV3EFaB5yEXUn+9FBkptQdJjZhs7KVrQJoP4+KIzpqt Weixhh0T7NHo4VSRbxH0Am/j1/nAkjl7n0tDd1eq+GL5lQAsI9paZGFYN/vEhWHLqfSS E+SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vhxSKjoSd1R7iDKXpsrK7l28NFZix7NigyHB90ikHtY=; b=cIVg/6A/t9UOAOYMP/kJh1EdSse8QjsUPfzjPqvdpka++f8KwMorIP57hRYyj+97JY VUZkUy1IadsRd5UtYa+NQBBd/N+ZCe6CfYPaH76rrHU/FgeKWdAekOgFrE1pwSOIW2Vo AdNU94xcp0uKAOo9mVsWCTs17yLIVHOaw50ONBW//fnNxbn26uv53AH62KO7e1rrFU8/ ZXVSA25XTthd9M5evi5Apv56GyyUQQaik7i2/aar4m4x7S9pr3ZI+QSwi5eVxMk3ZqFP unnjRC/NpP1HnBcruqrqnwlf9yNN5wl+XtpJwWn7Qkr89+lXOotGOJAkruDrZbircBRU +6LQ== X-Gm-Message-State: AOAM530/p88AR2yT76k2jZytWC9Kth7V05OPhipG441hpPBrz4u6p35Z M+byrtME1Ud3WC/SpRNq4B9d3M3k21/H5L5rzWs= X-Google-Smtp-Source: ABdhPJxn8bJLEyQ4MMdFcZr2zvxeqWPwZHjK+HJQUaIYdpcYLRCIELXfd6fgmyRGaCxMjmn2U30Mf2AGORxc9aUyCfg= X-Received: by 2002:a05:6a00:2bb:b029:1be:aeea:abf4 with SMTP id q27-20020a056a0002bbb02901beaeeaabf4mr125993pfs.63.1611848415354; Thu, 28 Jan 2021 07:40:15 -0800 (PST) MIME-Version: 1.0 References: <87a6tm2sxb.fsf@linaro.org> <878s941x85.fsf@linaro.org> <20210108083433.pfzhxrd4rezk6yxe@sirius.home.kraxel.org> <878s8zptrf.fsf@linaro.org> <87ft33l8an.fsf@linaro.org> <87v9blmf1x.fsf@linaro.org> <87o8h9wbh5.fsf@linaro.org> In-Reply-To: <87o8h9wbh5.fsf@linaro.org> From: Shreyansh Chouhan Date: Thu, 28 Jan 2021 21:10:03 +0530 Message-ID: Subject: Re: Fwd: VirtioSound device emulation implementation To: =?UTF-8?B?QWxleCBCZW5uw6ll?= Content-Type: multipart/alternative; boundary="0000000000003aaf1505b9f7b4b1" Received-SPF: pass client-ip=2607:f8b0:4864:20::42f; envelope-from=chouhan.shreyansh2702@gmail.com; helo=mail-pf1-x42f.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Gerd Hoffmann , qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --0000000000003aaf1505b9f7b4b1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 28 Jan 2021 at 16:54, Alex Benn=C3=A9e wro= te: > > Shreyansh Chouhan writes: > > > Thanks a lot Alex! > > > >> All QEMU devices have two parts, a frontend (which the guest sees) and= a > >> backend (which is how the data gets to somewhere in the host). Some of > >> the command line options in QEMU elide the details for convenience (-n= ic > >> and -drive are examples). The -netdev device is all about configuring > >> the backend of the network part for a paired -device front end. There = is > >> a similar setup for audio (-audiodev) although I'll defer to Gerd's > >> expertise on how the two interact. > > > > This helped me understand a bit more about how the devices work. In the > > source > > code, I found the `virtio-net-pci.c` and `virtio-net.c` files, I think > the > > pci device is what is visible to the guest. > > So `virtio-net-pci.c` should be the front end? > > No - they are both front-ends. In VirtIO you have two transports. The > first is virtio-mmio which is a simple set of memory mapped IO > registers. There is no discovery (well there is some but the guest needs > to find where in memory the mmio bus is via some method like hardcoded > address or DTB). > > The second is virtio-pci. Here the virtio devices are encapsulated in a > PCI bus so you get the benefits of discovery and bus enumeration. > So I am a bit confused here. First of there are two parts to a virtio device in general. One is the front end that the guest sees, and one is where the processing happens, which could be either in QEMU or as a separate daemon. In case of an in QEMU virtio device, the QEMU front end is replaced by the virtio-front end. Is that true? That's what I think should happen if both of those files are front ends. When you said earlier that all QEMU devices have two parts, I somehow thought that the in-QEMU backend for the audio device will itself have two parts. > > > For the realize function, I saw that the `virtio_net_device_realize` > > function initializes > > the `net_conf` for the device. So I am guessing that the > > `virtio_snd_device_realize` function > > should initialize the number of jacks and streams a device has, along > with > > the configuration > > for all these jacks and streams? > > No those are all front-end configuration knobs. > I am assuming these are set from the command-line or the configuration files. > > > The thing is I do not understand `net` devices all that well so I get a > bit > > confused with > > what is specific to a net device and what should I actually be worried > > about :) > > > > The device initalization step mentions that the jack and streams should > be > > read and > > a query should be made for the config of all jacks and streams. What > should > > be the > > default values of these configurations? I think the realize function is > > responsible > > for setting these up. > > Gerd? > > > > -- > Alex Benn=C3=A9e > -- Shreyansh --0000000000003aaf1505b9f7b4b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, 28 Jan 2021 at 16:54, Alex Be= nn=C3=A9e <alex.bennee@linaro.= org> wrote:

Shreyansh Chouhan <chouhan.shreyansh2702@gmail.com> writes:

> Thanks a lot Alex!
>
>> All QEMU devices have two parts, a frontend (which the guest sees)= and a
>> backend (which is how the data gets to somewhere in the host). Som= e of
>> the command line options in QEMU elide the details for convenience= (-nic
>> and -drive are examples). The -netdev device is all about configur= ing
>> the backend of the network part for a paired -device front end. Th= ere is
>> a similar setup for audio (-audiodev) although I'll defer to G= erd's
>> expertise on how the two interact.
>
> This helped me understand a bit more about how the devices work. In th= e
> source
> code, I found the `virtio-net-pci.c` and `virtio-net.c` files, I think= the
> pci device is what is visible to the guest.
> So `virtio-net-pci.c` should be the front end?

No - they are both front-ends. In VirtIO you have two transports. The
first is virtio-mmio which is a simple set of memory mapped IO
registers. There is no discovery (well there is some but the guest needs to find where in memory the mmio bus is via some method like hardcoded
address or DTB).

The second is virtio-pci. Here the virtio devices are encapsulated in a
PCI bus so you get the benefits of discovery and bus enumeration.
So I am a bit confused here. First of there are two parts to a = virtio device in general. One is the
front end that the guest see= s, and one is where the processing happens, which could be either in QEMU
or as a separate daemon. In case of an in QEMU virtio device, the = QEMU front end is replaced by the
virtio-front end. Is that true?= That's what I think should happen if both of those files are front end= s.

When you said earlier that all QEMU devices hav= e two parts, I somehow thought that
the in-QEMU backend for t= he audio device will itself have two parts.

> For the realize function, I saw that the `virtio_net_device_realize` > function initializes
> the `net_conf` for the device. So I am guessing that the
> `virtio_snd_device_realize` function
> should initialize the number of jacks and streams a device has, along = with
> the configuration
> for all these jacks and streams?

No those are all front-end configuration knobs.
I am = assuming these are set from the command-line or the configuration files.

> The thing is I do not understand `net` devices all that well so I get = a bit
> confused with
> what is specific to a net device and what should I actually be worried=
> about :)
>
> The device initalization step mentions that the jack and streams shoul= d be
> read and
> a query should be made for the config of all jacks and streams. What s= hould
> be the
> default values of these configurations? I think the realize function i= s
> responsible
> for setting these up.

Gerd?



--
Alex Benn=C3=A9e
--
Shreyansh
--0000000000003aaf1505b9f7b4b1--