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

[Halil Pasic]

On 10/05/2016 09:00 PM, Dr. David Alan Gilbert wrote:
> * Paolo Bonzini (address@hidden) 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. :)
> 
> Yes, it would.
> 
>> 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.
> 
> Well I think Halil's stuff moves it in the right direction;
> with everything in VIRTIO_DEF_DEVICE_VMSD it means we can move things
> out of virtio_load/save and into corresponding members in 
> VIRTIO_DEF_DEVICE_VMSD's
>  .fields array (before or after VMSTATE_VIRTIO_FIELD) without having
> to change any of the devices. Eventually virtio_load/save disappear.
>

I think this would end up messy if we want to preserve the current
behavior of virtio_load/save, and more importantly compatibility. AFAIU
we would have a 'synthetic' field for the configuration/transport
migration first, then a field dealing with the state in VirtIODevice
excluding config_vector and subsections (the state of virtio-core), then
we would have a sequence of fields dealing with the device specific
state of the transport agnostic virtio device (e.g. virtio-net,
virtio-gpu) that is emulate load/save from VirtIODeviceClass, then we
would have to take care of the virtio core subsections and possibly
device specific subsections (or have yet another synthetic field for
device specific subsections). This is actually the first thing I wanted
to do in response to "[RFC 0/6] converting some of virtio to VMState"
but after some thinking, concluded for myself that it will end up too
messy and way less readable that what Dave did there, without any
real gain to make the increased complexity justified.

Or am I mistaken here?

Halil