From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:37992)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <cornelia.huck@de.ibm.com>) id 1TYITt-0005UC-Dr
	for qemu-devel@nongnu.org; Tue, 13 Nov 2012 10:32:56 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <cornelia.huck@de.ibm.com>) id 1TYITq-0001C1-Ad
	for qemu-devel@nongnu.org; Tue, 13 Nov 2012 10:32:53 -0500
Received: from e06smtp11.uk.ibm.com ([195.75.94.107]:49476)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <cornelia.huck@de.ibm.com>) id 1TYITq-0001Bs-2A
	for qemu-devel@nongnu.org; Tue, 13 Nov 2012 10:32:50 -0500
Received: from /spool/local
	by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <qemu-devel@nongnu.org> from <cornelia.huck@de.ibm.com>;
	Tue, 13 Nov 2012 15:32:48 -0000
Received: from d06av08.portsmouth.uk.ibm.com (d06av08.portsmouth.uk.ibm.com
	[9.149.37.249])
	by b06cxnps3074.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with
	ESMTP id qADFWcqq57147612
	for <qemu-devel@nongnu.org>; Tue, 13 Nov 2012 15:32:38 GMT
Received: from d06av08.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av08.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with
	ESMTP id qADFWicX030771
	for <qemu-devel@nongnu.org>; Tue, 13 Nov 2012 08:32:45 -0700
Date: Tue, 13 Nov 2012 16:32:42 +0100
From: Cornelia Huck <cornelia.huck@de.ibm.com>
Message-ID: <20121113163242.613b3d07@BR9GNB5Z>
In-Reply-To: <50A258ED.7080807@greensocs.com>
References: <50A258ED.7080807@greensocs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] Virtio refactoring.
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: KONRAD =?UTF-8?B?RnLDqWTDqXJpYw==?= <fred.konrad@greensocs.com>
Cc: Peter Maydell <peter.maydell@linaro.org>, aliguori@us.ibm.com, Evgeny Voevodin <e.voevodin@samsung.com>, Mark Burton <mark.burton@greensocs.com>, qemu-devel@nongnu.org, agraf@suse.de

On Tue, 13 Nov 2012 15:27:57 +0100
KONRAD Fr=C3=A9d=C3=A9ric <fred.konrad@greensocs.com> wrote:

> To fix this, an idea is to use a new qbus named VirtioBus to link virtio-=
pci
> or virtio-mmio with all the virtio backend ( VirtioDevice ). So=20
> "virtio-pci" and
> "virtio-mmio" will have a VirtioBus.

Just to spell this out:

We'd go from

system bus
-> virtio transport bridge dev (virtio-xxx-bridge)
   -> virtio transport bus (virtio-xxx-bus)
      -> virtio transport dev (virtio-<type>-xxx)

to

system bus
-> virtio transport bridge dev (virtio-bridge-xxx)
   -> virtio bus (virtio-bus-xxx)
      -> virtio dev (virtio-<type>-xxx)

?

Would this also mean we could have several virtio-busses with different
transports?

>=20
> To do that we will do the following things in the right order :
>      * Introduce a new VirtioBus ( same way as scsi-bus.c ), with=20
> VirtIODevice
>        interface :
>           -> callback to completely abstract the VirtioDevice from=20
> VirtioPCI.
>           -> for the queue, load/save the queue/config, features, ...,=20
> other ?
>      * Add a VirtioBus to the VirtioPCIProxy. ( virtio-pci.c ) :
>           -> moving all to the newer callback.
>      * For each of the virtio-device : ( virtio-x.c )
>           -> making a separate class for virtio-x which is a VirtioDevice.
>           -> making a virtio-x-pci which has a virtio-x.
>      * Create virtio-mmio ( virtio-mmio.c ).
>=20
> Is it the right approach ? Do I miss something ?

What of the alias handling? Can this be killed once everything has been
converted?

>=20
> When it will work, we must be sure of :
>=20
> -> migration compatibility.
> -> not breaking the s390 transport.
> -> compatibility with s390 ccw.

There shouldn't be major problems rebasing the virtio-ccw code on top
of this rework (though I'd probably try to keep the basic channel I/O
support separate from this patchset).