qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v21 QEMU 4/5] virtio-balloon: Implement support for page pois


From: David Hildenbrand
Subject: Re: [PATCH v21 QEMU 4/5] virtio-balloon: Implement support for page poison tracking feature
Date: Fri, 24 Apr 2020 09:07:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

>>  GlobalProperty hw_compat_4_2[] = {
>>      { "virtio-blk-device", "queue-size", "128"},
>>      { "virtio-scsi-device", "virtqueue_size", "128"},
> 
> Okay, so the bit above is for after 5_0 is released then? Is there a

Yes.

> way to queue up a reminder or something so we get to it when the time
> comes, or I just need to watch for 5.0 to come out and submit a patch
> then?

I think what happened usually happens is that someone introduces all the
compat machines, sometimes directly with empty hw_compat.

E.g., see

commit 3eb74d2087d3bd6cb51c06a49ba94222248d2de4
Author: Cornelia Huck <address@hidden>
Date:   Tue Nov 12 11:48:11 2019 +0100

    hw: add compat machines for 5.0

    Add 5.0 machine types for arm/i440fx/q35/s390x/spapr.

and

commit 9aec2e52ce9d9632a86be2d1d0dd493722d2e7be
Author: Cornelia Huck <address@hidden>
Date:   Wed Jul 24 12:35:24 2019 +0200

    hw: add compat machines for 4.2

    Add 4.2 machine types for arm/i440fx/q35/s390x/spapr.


The latter already introduced hw_compat_4_1, for examnple.

@Conny, do you already have a patch for 5.1 compat patch lying around
somewhere?

[...]

> So I will probably go this route. It looks like that is the way we
> went for free page reporting so it is easy enough to just do some
> cut/paste/replace and have something ready to go later today without
> having to second guess things.


I remember that a v1->v2 vmstate migration works (e.g., old QEMU to new
QEMU). But I can't tell from the top of my head what would happen when
we migrate v2->v1 (e.g., new QEMU to old QEMU). My guess is that the
latter won't work, but I might be wrong.

Looking at migration/vmstate.c:vmstate_load_state()

"incoming version_id ... is too new for local version_id"

One would have to tell the new QEMU to send via vmstate v1 when running
under the compat machine. I don't recall if and how that would be
possible. So the other approach is a save bet.

-- 
Thanks,

David / dhildenb




reply via email to

[Prev in Thread] Current Thread [Next in Thread]