Peter Xu <peterx@xxxxxxxxxx> writes:
> On Tue, Jul 09, 2024 at 05:38:54PM -0300, Fabiano Rosas wrote:
>> Philippe Mathieu-Daudé <philmd@xxxxxxxxxx> writes:
>>
>> > "General command" (GEN_CMD, CMD56) is described as:
>> >
>> > GEN_CMD is the same as the single block read or write
>> > commands (CMD24 or CMD17). The difference is that [...]
>> > the data block is not a memory payload data but has a
>> > vendor specific format and meaning.
>> >
>> > Thus this block must not be stored overwriting data block
>> > on underlying storage drive. Keep it in a dedicated
>> > 'vendor_data[]' array.
>> >
>> > Signed-off-by: Philippe Mathieu-Daudé <philmd@xxxxxxxxxx>
>> > Tested-by: Cédric Le Goater <clg@xxxxxxxxxx>
>> > ---
>> > RFC: Is it safe to reuse VMSTATE_UNUSED_V() (which happens
>> > to be the same size)?
>>
>> Hi, sorry it took some time to get to this, I had just left for vacation
>> when you first posted.
>
> And I totally overlooked there's the email.. until you replied. Welcome
> back.
Thanks!
>
>>
>> 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.
