[Top][All Lists]

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

Re: [Qemu-devel] Can we improve virtio data structures with QOM?

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>
Ordinary device models have a single state struct. The first member is
a 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

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 and
then 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).


Anthony Liguori

Adding 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.



Anthony Liguori

Added 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

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

reply via email to

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