On Wed, Jul 10, 2024 at 11:08:20AM -0300, Fabiano Rosas wrote:
> >> I think it's ok:
> >>
> >> {
> >> "field": "unused",
> >> "version_id": 1,
> >> "field_exists": false,
> >> "size": 512
> >> },
> >>
> >> vs.
> >>
> >> {
> >> "field": "vendor_data",
> >> "version_id": 0,
> >> "field_exists": false,
> >> "num": 512,
> >> "size": 1
> >> },
> >>
> >> The unused field was introduced in 2016 so there's no chance of
> >> migrating a QEMU that old to/from 9.1.
> >
> > What happens if an old qemu 9.0 sends rubbish here to a new QEMU, while the
> > new QEMU would consider it meaningful data?
>
> It will send zeros, no? The code will have to cope with that. The
> alternative is to put the vendor_data in a subsection and the code will
> also have to cope with the lack of data when the old QEMU doesn't send
> it.
Ah indeed, that "static const uint8_t buf[1024]" is there at least since
2017. So yes, probably always sending zeros.
Nothing I can think of otherwise indeed, if we want to trust that nothing
will migrate before 2016. It's just that we may want to know how that
"2016" is justified to be safe if we would like to allow that in the
future.
One thing _could_ be that "rule of thumb" is we plan to obsolete machines
with 6 years, so anything "UNUSED" older than 6 years can be over-written?
--
Peter Xu
