qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Why one virtio-pci device has two different DeviceState


From: Peter Maydell
Subject: Re: [Qemu-devel] Why one virtio-pci device has two different DeviceState?
Date: Sat, 5 Jan 2019 15:42:18 +0000

On Fri, 4 Jan 2019 at 20:23, Jintack Lim <address@hidden> wrote:
> I was wondering why one virtio-pci device has two different
> DeviceState? - one directly from VirtIOPCIProxy and the other from
> VirtIO<dev type> such as VirtIONet. As an example, they are denoted as
> qdev and vdev respectively in virtio_net_pci_realize().

It's been a while since I looked at this, but there are two
basic issues underlying the weird way virtio devices are
set up:
 (1) PCI is not the only "transport" -- the VirtIONet etc
     are shared with other transports like MMIO or the S390 ones
 (2) retaining back-compatibility matters a lot here: we need
     command lines to still work, and also the migration data
     stream needs to stay compatible
Some of the way the devices are reflects the way we started
with a design where there was only a single device (eg the
pci virtio-net device) and then refactored it to support
multiple transports while retaining back compatibility.

> I thought that just one DeviceState is enough for any device in QEMU.
> Maybe I'm missing something fundamental here.

This isn't generally true, it's just that a lot of
our devices are of the simple straightforward kind
where that's true. It's also possible for an
implementation of a device to be as a combination
of other devices, which is what we have here.
virtio-pci-net is-a PCIDevice (which in turn is-a Device),
but it has-a VirtIONet device (which is-a Device) as
part of its implementation.
(It's also possible to manually create the pci
transport and the virtio-net backend separately
and connect them together without the virtio-pci-net
device at all. That's more often used with non-pci
transports but it works for pci too.)

You can also see a similar thing with a lot of the
"container" SoC objects like TYPE_ASPEED_SOC, which
is a subclass of DeviceState, but is implemented
using a dozen different objects all of which are
themselves DeviceState subclasses.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]