On Thu, Jan 28, 2021 at 09:58:23AM +0530, Shreyansh Chouhan wrote: > 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 (-nic > > 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?
Well, virtio can have different transports, thats why the separation. pci is the most common one, but there are also mmio (supported by x86 microvm and arm/aarch64 virt) and ccw (used on s390x). virtio-net.c is the actual virtio device, virtio-net-pci.c has mostly glue code to make the virtio device visible on the pci bus. > 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? Yes. net_conf is common config (backend, mac address, maybe more) for network devices. For sound devices that would audiodev (link the device to a backend which then handles alsa/pulse/jack/oss/sdl/whatever). Configuration can be done either using device properties, or by having different devices. Using device properties is probably the easier way to go. An example for the latter are the qemu hda codecs. We have three different devices: (1) hda-output: playback-only, offering a virtual line-out. (2) hda-duplex: record/playback, offering line-in and line-out. (3) hda-micro: record/playback, offering microphone and speaker. The difference between (2) and (3) is just the jack labeling, otherwise the behavior is 100% identical (and they share the emulation code of course). But some windows VoIP apps didn't like the line-in and complained about a missing microphone, so we added that ... > 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 only thing really required is the audiodev property. Everything else can be hard-coded initially, and once the basics are working refined (like adding properties for jack labels, ...). > 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. I'd start with offering a single 48000, 16bit, stereo, line-out pcm playback channel. HTH, Gerd
