On Thu, Jan 28, 2021 at 09:20:31PM +0530, Shreyansh Chouhan wrote:
> (Gerd, I wasn't able to get gmail to quote your email, so I have just copy
> pasted the relavant parts.)
>
> > 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).
>
> Ah I see, so the net_conf corresponds to audiodev?
Oops. Confused that. nic_conf (struct NICConf) is the common config
for all network devices, not net_conf.
See DEFINE_NIC_PROPERTIES() in include/net/net.h
NICConf.peers (exposed as "netdev" property) links the emulated device
(frontend) to a netdev (backend) which actually processes the packets
sent by the guest.
In a simliar way the audiodev property links the emulated audio device
to a backend which handles the host-side audio playback using alsa,
pulseaudio or something else.
> I thought it would correspond to `virtio_snd_conf`. So as alex said,
> `virtio_snd_conf` is the front end configuration.
Correct.
The backend is configured separately, i.e.
-netdev user,id=net0,$moreargs
or
-audiodev alsa,id=snd0,$moreargs
Then the two are linked by id, i.e.
-device virtio-net-pci,netdev=net0
or
-device virtio-sound-pci,audiodev=snd0
Ah ha! So `virtio-snd-conf` corresponds to the `-device` configuration
and `audiodev` to the backend configuration. I think the audio code
now makes more sense to me. I will give it another read.
> > 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, ...).
>
> So in the realize function I set up the audiodev, right? Also in that case
> why the difference between the net and sound devices? In the net
> device we set up the common config in net_conf. Does the net_conf
> somehow later sets up NetDev too?
>
> And what is a NetClientState? Is the NetClient the emulated guest? This
> confuses me a lot. I can't understand what will be the parellel audio device
> property.
Not fully sure what NetClientState is, I guess it is shared struct for
both frontend and backend to manage the connection state.
The audio subsystem has simliar structs, SWVoiceIn and SWVoiceOut for
example. There also is QEMUSoundCard. I'd suggest to check out the
source code of other audio devices for code examples.
I will read it and revert back if I have any queries.
> Also I can't seem to find where we parse the command line options
> passed to qemu. The code structure is a bit different from what I had
> expected. In virtio_net_device_realize we set duplex to half or full
> depending on the value of the net_conf.duplex_str. But I couldn't find
> where we actually set it.
See virtio_net_properties[]. There is a line in the array:
DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str),
I thought this just declared a property, and didn't set it. But now that in retrospect
we already declared the variable when we defined the struct so that doesn't make
sense.
And the whole array is registered using:
device_class_set_props(dc, virtio_net_properties);
That is enough to make those properties work, the qemu core handles
everything for you. See hw/core/qdev-properties.c if you are curious,
but you can also just consider that a black box at service for you ;)
I think I will give it a quick look :P
take care,
Gerd
Thanks a lot!
--
Shreyansh