All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cornelia.huck@de.ibm.com>
To: "KONRAD Frédéric" <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
Subject: Re: [Qemu-devel] Virtio refactoring.
Date: Tue, 13 Nov 2012 16:32:42 +0100	[thread overview]
Message-ID: <20121113163242.613b3d07@BR9GNB5Z> (raw)
In-Reply-To: <50A258ED.7080807@greensocs.com>

On Tue, 13 Nov 2012 15:27:57 +0100
KONRAD Frédéric <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 
> "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?

> 
> To do that we will do the following things in the right order :
>      * Introduce a new VirtioBus ( same way as scsi-bus.c ), with 
> VirtIODevice
>        interface :
>           -> callback to completely abstract the VirtioDevice from 
> VirtioPCI.
>           -> for the queue, load/save the queue/config, features, ..., 
> 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 ).
> 
> Is it the right approach ? Do I miss something ?

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

> 
> When it will work, we must be sure of :
> 
> -> 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).

  reply	other threads:[~2012-11-13 15:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-13 14:27 [Qemu-devel] Virtio refactoring KONRAD Frédéric
2012-11-13 15:32 ` Cornelia Huck [this message]
2012-11-13 16:31   ` KONRAD Frédéric
2012-11-13 18:09     ` Cornelia Huck
2012-11-15 10:32       ` KONRAD Frédéric
2012-11-15 12:05         ` Cornelia Huck
2012-11-13 23:00   ` Andreas Färber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121113163242.613b3d07@BR9GNB5Z \
    --to=cornelia.huck@de.ibm.com \
    --cc=agraf@suse.de \
    --cc=aliguori@us.ibm.com \
    --cc=e.voevodin@samsung.com \
    --cc=fred.konrad@greensocs.com \
    --cc=mark.burton@greensocs.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.