* [Qemu-devel] Why one virtio-pci device has two different DeviceState?
@ 2019-01-04 20:21 Jintack Lim
2019-01-05 15:42 ` Peter Maydell
0 siblings, 1 reply; 3+ messages in thread
From: Jintack Lim @ 2019-01-04 20:21 UTC (permalink / raw)
To: QEMU Devel Mailing List; +Cc: Peter Xu
Hi,
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().
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] Why one virtio-pci device has two different DeviceState?
2019-01-04 20:21 [Qemu-devel] Why one virtio-pci device has two different DeviceState? Jintack Lim
@ 2019-01-05 15:42 ` Peter Maydell
2019-01-07 3:42 ` Jintack Lim
0 siblings, 1 reply; 3+ messages in thread
From: Peter Maydell @ 2019-01-05 15:42 UTC (permalink / raw)
To: Jintack Lim; +Cc: QEMU Devel Mailing List, Peter Xu
On Fri, 4 Jan 2019 at 20:23, Jintack Lim <jintack@cs.columbia.edu> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] Why one virtio-pci device has two different DeviceState?
2019-01-05 15:42 ` Peter Maydell
@ 2019-01-07 3:42 ` Jintack Lim
0 siblings, 0 replies; 3+ messages in thread
From: Jintack Lim @ 2019-01-07 3:42 UTC (permalink / raw)
To: Peter Maydell; +Cc: QEMU Devel Mailing List, Peter Xu
On Sat, Jan 5, 2019 at 10:42 AM Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Fri, 4 Jan 2019 at 20:23, Jintack Lim <jintack@cs.columbia.edu> 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.
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
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-01-07 3:42 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-04 20:21 [Qemu-devel] Why one virtio-pci device has two different DeviceState? Jintack Lim
2019-01-05 15:42 ` Peter Maydell
2019-01-07 3:42 ` Jintack Lim
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.