qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH v2 0/3] Virtio-refactoring.


From: Konrad Frederic
Subject: Re: [Qemu-devel] [RFC PATCH v2 0/3] Virtio-refactoring.
Date: Mon, 26 Nov 2012 10:00:21 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.5) Gecko/20120623 Thunderbird/10.0.5

On 23/11/2012 17:18, Stefan Hajnoczi wrote:
On Fri, Nov 23, 2012 at 03:29:52PM +0100, Konrad Frederic wrote:
On 23/11/2012 13:38, Stefan Hajnoczi wrote:
On Thu, Nov 22, 2012 at 03:50:49PM +0100, address@hidden wrote:
From: KONRAD Frederic<address@hidden>
I made the changes you suggest in the last RFC.

There are still two issues with the command line :

     * When I use ./qemu* -device virtio-blk -device virtio-pci
       It is said that no virtio-bus are present.
     * The virtio-blk is plugged in the last created virtio-bus if no "bus="
       option is present. It's an issue as we can only plug one virtio-device.

The first problem is a more general issue as it is the case for the SCSI bus and
can be fixed later.
Thanks for sharing virtio refactoring progress.

I think the challenge will be truly converting existing code over to the
new approach.  This RFC series adds a new layer on top of the existing
code but doesn't actually replace it.

Would be interesting to see the complete picture, even if you need to
leave some TODOs in the middle when sending RFC patches.

Stefan
Yes, sure.

So the next would be :
     * use QOM interface in place of VirtioBusInfo ?
This is probably a detail.  It probably doesn't make a big difference in
the RFC series.

     * refactor the VirtIODevice to remove VirtIOBinding ?
Yes, it would be nice to make your design the core and push the
compatibility stuff ("virtio-blk-pci", etc) to a layer on top, instead
of leaving the existing code as the core and putting QOM on top.
Ok, I'll do that.
I though modifying the less I can the VirtIODevice as it could break
all the s390 devices.
Sure and I think you've done a good job at showing incremental patches
vs a big bang approach that replaces everything in one patch.

Stefan
Thanks,

Fred



reply via email to

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