|
From: | Evgeny Voevodin |
Subject: | Re: [Qemu-devel] Can we improve virtio data structures with QOM? |
Date: | Thu, 31 May 2012 09:23:49 +0400 |
User-agent: | Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 |
On 31.05.2012 08:53, Anthony Liguori wrote:
On 05/31/2012 12:06 PM, Evgeny Voevodin wrote:On 31.05.2012 03:02, Anthony Liguori wrote:On 05/31/2012 12:28 AM, Markus Armbruster wrote:Stefan Hajnoczi<address@hidden> writes:On Wed, May 30, 2012 at 1:01 PM, Markus Armbruster<address@hidden> wrote:Ordinary device models have a single state struct. The first member isa DeviceState or a specialization of DeviceState, e.g. a PCIDevice. Simple enough.I think Evgeny's virtio mmio patches change all this. In the recent virtio-pci thread we were discussing how the virtio transport (mmio, pci) and virtio devices (net, blk, etc) fit together. The email thread is "Virtio-pci issues" from Evgeny Voevodin <address@hidden>.Thanks for the pointer. It's been a couple of weeks. Evgeny, are you still pursuing this?It probably makes sense to first merge Evgeny's virtio refactoring andthen ensure it's nicely mapped to QOM.Yes, no good attempting to do too much in one series. Nevertheless, having a sufficiently developed idea of the final state in mind helps.Basically, it should look like: VirtioPCIDevice is-a PCIDevice VirtioPCIDevice has-a link<VirtioDevice> VirtioDevice is-a DeviceState VirtioBlk is-a VirtioDevice VirtioNet is-a VirtioDevice ... VirtioPCIBlk is-a VirtioPCIDevice VirtioPCIBlk has-a child<VirtioBlk> This gives us backwards compat while also providing a cleaner model.VirtioPCIBlk et al would be deprecated eventually (but not any time soon).Regards, Anthony LiguoriAdding Peter in CC. Do not forget that we also have (will have, I hope) VirtioMMIO. And the last point I've stopped at (because of a lot of Tizen work) is: Added transport devices and bus: VirtioMMIOTransport is SysBusDevice VirtioPCITransport is PCIDevice VirtioMMIOTransport and VirtioPCITransport have VIRTIO_TRANSPORT_BUS.You mean: VirtioMMIOTransport implements VirtioTransportBus VirtioPCITransport implements VirtioTransportBus
Exactly. Thanks to Peter for a hint :)
That's the best way to do this IMHO. We also need: VirtioDevice has-a link<VirtioTransportBus>
Can you please clarify to me why we need both bus and link?I thought that both these instances are to let devices communicate. And if devices can communicate
through bus (or link) why we need other instance?
I think Having the word "Transport" is overly verbose. I think VirtioMMIO and VirtioPCI is fine.
Ok.
Regards, Anthony LiguoriAdded back-ends: VirtioNet, VirtioBlk, etc are DeviceState and all of them have .bus_info initialised to VIRTIO_TRANSPORT_BUS. So, functionally we don't need to create new VirtioDevice class because it seems that for now we have all we need, but for cleaner model (and maybe at QOM's point of view too) I think it's worth to. This work is not completed and have issues pointed out here http://lists.gnu.org/archive/html/qemu-devel/2012-05/msg01421.html Since I'm not sure if I have time to finish this until our project milestone I can send an RFC patch-set and describe all it's issues to let somebody continue if this matter is urgent. But I'm still planning to continue this as soon as possible )
-- Kind regards, Evgeny Voevodin, Leading Software Engineer, ASWG, Moscow R&D center, Samsung Electronics e-mail: address@hidden
[Prev in Thread] | Current Thread | [Next in Thread] |