>>> +
>>> +static int virtio_mem_pre_save(void *opaque)
>>> +{
>>> +VirtIOMEM *vmem = VIRTIO_MEM(opaque);
>>> +
>>> +vmem->migration_addr = vmem->addr;
>>> +vmem->migration_block_size = vmem->block_size;
>>
>> You might look at VMSTATE_WITH_TMP could avoid you having the dummy
>> fields
On 15.05.20 17:37, Dr. David Alan Gilbert wrote:
> I'm not sure if it's possible to split this up; it's a bit big.
Functionality-wise, it's the bare minimum. I could split out handling of
all 4 request types, but they are only ~150-200 LOC. Not sure if that is
really worth the trouble. open for su
I'm not sure if it's possible to split this up; it's a bit big.
It could also do with a pile of trace_ entries to figure out what it's
doing.
* David Hildenbrand (da...@redhat.com) wrote:
> This is the very basic/initial version of virtio-mem. An introduction to
> virtio-mem can be found in the L
>> +##
>> +{ 'struct': 'VirtioMEMDeviceInfo',
>> + 'data': { '*id': 'str',
>> +'memaddr': 'size',
>> +'requested-size': 'size',
>> +'size': 'size',
>> +'max-size': 'size',
>> +'block-size': 'size',
>> +'node': 'int',
>> +
On 5/6/20 4:49 AM, David Hildenbrand wrote:
This is the very basic/initial version of virtio-mem. An introduction to
virtio-mem can be found in the Linux kernel driver [1]. While it can be
used in the current state for hotplug of a smaller amount of memory, it
will heavily benefit from resizeable