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: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [RFC PATCH v2 0/3] Virtio-refactoring.
Date: Fri, 23 Nov 2012 17:18:40 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

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.

> 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



reply via email to

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