On 19.03.26 22:57, Peter Xu wrote:
CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.



On Thu, Mar 19, 2026 at 05:56:52PM -0300, Fabiano Rosas wrote:
Peter Xu <[email protected]> writes:

The loader side of ptr marker is pretty straightforward, instead of playing
the inner_field trick, just do the load manually assuming the marker layout
is a stable ABI (which it is true already).

This will remove some logic while loading VMSD, and hopefully it makes it
slightly easier to read.  Unfortunately, we still need to keep the sender
side because of the JSON blob we're maintaining..

/ramble
Is the JSON blob ABI? Can we kill it?
Yeah, that's a fair ramble.  I had sometimes the same feeling that I wished
it not be there, it'll save quite some work..

Per my limited understanding of reading the code in the past, the plan 10
years ago was having those blob to always be together with the binary
stream so that the stream (especially when causing loading failures..) will
be parsable and it's easier to know why the load fail.

However I also confess in the past few years since I worked on migration, I
never used it to debug any real VMSD issues..

I think one reason might be that when migration was very new and when
device emulation developers were easier to mess things up, crash happen
more, and at that time this tool helps debugging things.  It'll also almost
make the VM dump self-explanatory.

Nowadays, we added more codes into migration to help, e.g., I recall we
added things like QEMU_VM_SECTION_FOOTER and likely more after the vmdesc,
which can also help to identify VMSD issues directly from dest QEMU errors.

Let me copy some more people to see if there's any thoughts or inputs on
the JSON blobs..


I added and used it for 2 purposes:

1. To make the actual content of the device state more clearly visible. It can help to stare at a device state dump to find out what's going wrong. 2. To allow for state diffing. When I introduced it, I would do a migration to file, run my test, do another migration and then diff the vmstates. That way I could easily see what actually changed between the runs. It helped me identify a few CPU register state issues.

I don't believe I ever ended up using it to debug live migration issues :).


Alex




Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597

Reply via email to