Re: [PATCH v3 7/8] virtio-mem: Migrate immutable properties early

[David Hildenbrand]

On 12.01.23 20:44, Dr. David Alan Gilbert wrote:
> * David Hildenbrand (david@redhat.com) wrote:
> > The bitmap and the size are immutable while migration is active: see
> > virtio_mem_is_busy(). We can migrate this information early, before
> > migrating any actual RAM content. Further, all information we need for
> > sanity checks is immutable as well.
> >
> > Having this information in place early will, for example, allow for
> > properly preallocating memory before touching these memory locations
> > during RAM migration: this way, we can make sure that all memory was
> > actually preallocated and that any user errors (e.g., insufficient
> > hugetlb pages) can be handled gracefully.
> >
> > In contrast, usable_region_size and requested_size can theoretically
> > still be modified on the source while the VM is running. Keep migrating
> > these properties the usual, late, way.
> >
> > Use a new device property to keep behavior of compat machines
> > unmodified.
>
> Can you get me a migration file from this? I want to try and understand
> what happens when you have the vmstate_register together with the ->vmsd -
> I'm not quite sure what ends up in the output.  Preferably for a VM with
> two virtio-mem's.

Sure, here is the stripped output from analyze-migration.py:

    "ram (2)": {
        "section sizes": {
            "0000:00:03.0/mem0": "0x0000000780000000",
            "0000:00:04.0/mem1": "0x0000000780000000",
            "pc.ram": "0x0000000100000000",
            "/rom@etc/acpi/tables": "0x0000000000020000",
            "pc.bios": "0x0000000000040000",
            "0000:00:02.0/e1000.rom": "0x0000000000040000",
            "pc.rom": "0x0000000000020000",
            "/rom@etc/table-loader": "0x0000000000001000",
            "/rom@etc/acpi/rsdp": "0x0000000000001000"
        }
    },
    "0000:00:03.0/virtio-mem-device-early (51)": {
        "tmp": "00 00 00 01 40 00 00 00 00 00 00 07 80 00 00 00 00 00 00 00 00 20 00 
00 00 00 00 00",
        "size": "0x0000000040000000",
        "bitmap": "ff ff ff ff [...] "
    },
    "0000:00:04.0/virtio-mem-device-early (53)": {
        "tmp": "00 00 00 08 c0 00 00 00 00 00 00 07 80 00 00 00 00 00 00 00 00 20 00 
00 00 00 00 00",
        "size": "0x00000001fa400000",
        "bitmap": "ff ff ff ff [...] "
    },
    "timer (0)": {
        "cpu_ticks_offset": "0x00000073f5ba3d28",
        "unused": "00 00 00 00 00 00 00 00",
        "cpu_clock_offset": "0x00000026b744e29c"
    },
[...]
    "serial (50)": {
        "state": {
            "divider": "0x0001",
            "rbr": "0x00",
            "ier": "0x05",
            "iir": "0xc1",
            "lcr": "0x13",
            "mcr": "0x0b",
            "lsr": "0x60",
            "msr": "0xb0",
            "scr": "0x00",
            "fcr_vmstate": "0x81"
        }
    },
    "0000:00:03.0/virtio-mem (52)": {
        "virtio": "00 00 00 02 f4 1a 58 10 07 01 10 00 01 00 ff [...]"
    "0000:00:04.0/virtio-mem (54)": {
        "virtio": "00 00 00 02 f4 1a 58 10 07 01 10 00 01 00 ff [...]"

The data of both "virtio" blobs is extremely large, a lot 0x00 -- no idea what 
virtio
core stores in there.

Note that vmstate_virtio_mem_device ("virtio-mem-device") will be included by 
virtio core in the
"virtio" blob.

I can send you a full savevm file privately, just ping me.

--
Thanks,

David / dhildenb