Re: [Qemu-devel] Why one virtio-pci device has two different DeviceState?
On Sat, Jan 5, 2019 at 10:42 AM Peter Maydell wrote: > > On Fri, 4 Jan 2019 at 20:23, Jintack Lim wrote: > > I was wondering why one virtio-pci device has two different > > DeviceState? - one directly from VirtIOPCIProxy and the other from > > VirtIO 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. Thanks for the insight, Peter. That make sense!! Thanks, Jintack > > > 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 >
Re: [Qemu-devel] Why one virtio-pci device has two different DeviceState?
On Fri, 4 Jan 2019 at 20:23, Jintack Lim wrote: > I was wondering why one virtio-pci device has two different > DeviceState? - one directly from VirtIOPCIProxy and the other from > VirtIO 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
[Qemu-devel] Why one virtio-pci device has two different DeviceState?
Hi, I was wondering why one virtio-pci device has two different DeviceState? - one directly from VirtIOPCIProxy and the other from VirtIO such as VirtIONet. As an example, they are denoted as qdev and vdev respectively in virtio_net_pci_realize(). I thought that just one DeviceState is enough for any device in QEMU. Maybe I'm missing something fundamental here. *Just* for people who wonder why I'm asking this question, I'd like to find a device in the list of SaveStateEntry on a MMIO operation to a PCI device. For virtio devices, I only have qdev information in the MMIO handler while I need to have vdev information to find the virtio device in the SaveStateEntry list. I can possibly do this by converting qdev to vdev knowing this is a virtio device as in virtio_net_pci_realize(), but I'd like to find a way to do it without knowing the device is a virtio device. Thanks, Jintack
