Re: [Qemu-devel] [PATCH 01/12] virtio: add VIRTIO_DEF_DEVICE_VMSD macro

[Halil Pasic]

On 10/05/2016 05:52 PM, Paolo Bonzini wrote:
> 
> On 05/10/2016 16:29, Dr. David Alan Gilbert wrote:
>> > The virtio-input conversion especially is nice and simple.
>> > The only weird case is virtio-gpu, and well virtio-gpu is the one that's
>> > odd here (compared to the rest of virtio).
> Though virtio-gpu would be the one that could become nicer without the
> macros. :)
> 
> What I don't like about the macros is that they don't allow you to
> extend the VMStateDescription.  However, if you agree with Halil your
> opinion counts more.
> 
> Paolo
> 

Hi guys!

Paolo you probably mean the fields part of the VMStateDescription. In my
opinion it is an important question if we should want the ability to
extend there. I was basing my assumptions on the series "[RFC 0/6]
converting some of virtio to VMState" by Dave. This series designates
VirtioDeviceClass.vmsd as the place for the state description of a
specialized device which would normally belong to where Paolo wants it.
The trouble in my opinion comes from the need to maintain compatibility
which basically means put the data exactly the way it was.

I do agree with Paolo that for new devices where this constrain is
non-existent we could and probably should get rid of the virtio
migration is very special stuff and do it normally. But for that in my
opinion we first need to figure out what is the new way of virtio
migration, document it, and provide an internal API for it. If we are
going to do that, I think it will actually turn out beneficial, that if
we name the weird (legacy) stuff differently because we can then name
the new not-so-weird stuff according to the normal conventions.

IMHO couple of questions to be answered before drafting the new approach
are:
* Is the proxy device (basically the transport) migrating itself or
is it migrated by the transport agnostic device (e.g. virtio-net)? In my
opinion these are two separate QOM/QDEV devices so they migrate
separately.  But this would arise some problems.
* How is inheritance and VMState is supposed to work together, including
versioning?

In the meanwhile I have re-implemented the series following Paolo's
suggestions (at least I hope) so I will send it out as a v2 shortly so we
can make a direct comparison.

Cheers,
Halil