[Qemu-devel] Virtio refactoring.

[Qemu-devel] Virtio refactoring.

[KONRAD Frédéric]

Hi,

Just to be sure that we are all understanding the same thing about the 
virtio
refactoring.

The old patch-set ( git://git.greensocs.com/qemu_virtio.git virtio ) I 
sent was
not good because :

* It use a custom transport property ( e.g : transport=virtio-mmio.0 ) for
   selecting a transport device between refactored virtio-pci and 
virtio-mmio
   which isn't QOM compliant.
* It wasn't easily reviewable, because the virtio-pci-new.c file is 
created at
   the beginning of the patch-set in order to keep virtio-pci.c ( and not
   breaking the virtio-*-pci devices ).

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.

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 ?

When it will work, we must be sure of :

-> migration compatibility.
-> not breaking the s390 transport.
-> compatibility with s390 ccw.

Fred

Re: [Qemu-devel] Virtio refactoring.

[Cornelia Huck]

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

Re: [Qemu-devel] Virtio refactoring.

[KONRAD Frédéric]

On 13/11/2012 16:32, Cornelia Huck wrote:
> 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)
>
> ?
I'm not sure of what you mean,.. do you mean for s390 ?

for the moment we have e.g : virtio-blk-pci ( in virtio-pci.c )

and we want virtio-pci -> virtio-bus -> virtio-blk.

( or virtio-mmio -> virtio-bus -> virtio-blk. for pci-less system. )

>
> Would this also mean we could have several virtio-busses with different
> transports?
I think so.
>
>> 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?
Which alias ?
>
>> 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).
>

Re: [Qemu-devel] Virtio refactoring.

[Cornelia Huck]

On Tue, 13 Nov 2012 17:31:40 +0100
KONRAD Frédéric <fred.konrad@greensocs.com> wrote:

> On 13/11/2012 16:32, Cornelia Huck wrote:
> > 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)
> >
> > ?
> I'm not sure of what you mean,.. do you mean for s390 ?
> 
> for the moment we have e.g : virtio-blk-pci ( in virtio-pci.c )
> 
> and we want virtio-pci -> virtio-bus -> virtio-blk.
> 
> ( or virtio-mmio -> virtio-bus -> virtio-blk. for pci-less system. )

I meant the structure you see in 'info qtree'. We might be talking
about the same thing :)

> >> Is it the right approach ? Do I miss something ?
> > What of the alias handling? Can this be killed once everything has been
> > converted?
> Which alias ?

The alias stuff in hw/qdev-monitor.c that lets you specify either
virtio-<type>-<transport> or virtio-<type>.

Re: [Qemu-devel] Virtio refactoring.

[Andreas Färber]

Am 13.11.2012 16:32, schrieb Cornelia Huck:
> On Tue, 13 Nov 2012 15:27:57 +0100
> KONRAD Frédéric <fred.konrad@greensocs.com> wrote:
>>      * 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?

AFAIU yes, but we may need to add new aliases for the long versions
(virtio-blk-pci) instead. ;)

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] Virtio refactoring.

[KONRAD Frédéric]

Hi,

On 13/11/2012 19:09, Cornelia Huck wrote:
> On Tue, 13 Nov 2012 17:31:40 +0100
> KONRAD Frédéric <fred.konrad@greensocs.com> wrote:
>>
>> 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)
>>
>> ?
>> I'm not sure of what you mean,.. do you mean for s390 ?
>>
>> for the moment we have e.g : virtio-blk-pci ( in virtio-pci.c )
>>
>> and we want virtio-pci -> virtio-bus -> virtio-blk.
>>
>> ( or virtio-mmio -> virtio-bus -> virtio-blk. for pci-less system. )
> I meant the structure you see in 'info qtree'. We might be talking
> about the same thing :)
For the qtree structure we have eg for virtio block :

bus: main-system-bus
   type System
   dev: pcihost, id ""
     bus: pci.0
       type PCI
       dev: virtio-blk-pci, id ""
         ...

And it would become :

bus: main-system-bus
   type System
   dev: pcihost, id ""
     bus: pci.0
       type PCI
       dev: virtio-pci, id ""
         bus: virtio.0
           type VIRTIO
           dev: virtio-blk, id ""
             ...

>
>>>> Is it the right approach ? Do I miss something ?
>>> What of the alias handling? Can this be killed once everything has been
>>> converted?
>> Which alias ?
> The alias stuff in hw/qdev-monitor.c that lets you specify either
> virtio-<type>-<transport> or virtio-<type>.
>
So it would break the alias, we must find a solution for that.

Fred

Re: [Qemu-devel] Virtio refactoring.

[Cornelia Huck]

On Thu, 15 Nov 2012 11:32:13 +0100
KONRAD Frédéric <fred.konrad@greensocs.com> wrote:


> For the qtree structure we have eg for virtio block :
> 
> bus: main-system-bus
>    type System
>    dev: pcihost, id ""
>      bus: pci.0
>        type PCI
>        dev: virtio-blk-pci, id ""
>          ...
> 

My current virtio-ccw layout is:

bus: main-system-bus
  type System
  dev: virtio-ccw-bridge, id ""
    bus: virtio-ccw
      type virtio-ccw-bus
      dev: virtio-blk-ccw, id ""
        ...

> And it would become :
> 
> bus: main-system-bus
>    type System
>    dev: pcihost, id ""
>      bus: pci.0
>        type PCI
>        dev: virtio-pci, id ""
>          bus: virtio.0
>            type VIRTIO
>            dev: virtio-blk, id ""
>              ...
> 

I guess we could have the following for virtio-ccw:

bus: main-system-bus
  type System
  dev: css, id ""
    bus: css.fe
      type ccw
      dev: virtio-ccw, id ""
        bus: virtio.0
          type virtio
          dev: virtio-blk, id ""
          ...

IOW, we introduce a channel subsystem (css) analogous to pcihost, have
a ccw bus which can hold all kinds of channel devices, introduce a bus
per channel subsystem image (here: the virtual css fe) and stick the
virtio bus under it. If we want to support passthrough of real channel
devices some day, they get their own bus for their channel subsystem
(css.0, css.1, ...) and have the devices show up under it.

(Just thinking aloud. I'll probably need to play with that idea a bit.)

> >
> >>>> Is it the right approach ? Do I miss something ?
> >>> What of the alias handling? Can this be killed once everything has been
> >>> converted?
> >> Which alias ?
> > The alias stuff in hw/qdev-monitor.c that lets you specify either
> > virtio-<type>-<transport> or virtio-<type>.
> >
> So it would break the alias, we must find a solution for that.

I think only virtio-xxx-pci and s390-virtio-xxx need to get backward
compatibility; virtio-mmio and virtio-ccw should not need to deal with
old interfaces.