Re: [PATCH v3 06/17] hw/usb/hcd-ehci: Change descriptor addresses to 64-bit

[Peter Xu <peterx@redhat.com>]

On Mon, Apr 20, 2026 at 05:56:11AM +0000, Jamin Lin wrote:
> Hi Peter, Philippe, Cédric

Hi, Jamin,

[...]

> > > > @@ -2501,8 +2515,12 @@ const VMStateDescription vmstate_ehci = {
> > > >           /* schedule state */
> > > >           VMSTATE_UINT32(astate, EHCIState),
> > > >           VMSTATE_UINT32(pstate, EHCIState),
> > > > -        VMSTATE_UINT32(a_fetch_addr, EHCIState),
> > > > -        VMSTATE_UINT32(p_fetch_addr, EHCIState),
> > > > +        VMSTATE_UINT32_TEST(a_fetch_addr_pre_v3, EHCIState,
> > > > +                            ehci_core_is_before_version_3),
> > > > +        VMSTATE_UINT32_TEST(p_fetch_addr_pre_v3, EHCIState,
> > > > +                            ehci_core_is_before_version_3),
> > > > +        VMSTATE_UINT64_V(a_fetch_addr, EHCIState, 3),
> > > > +        VMSTATE_UINT64_V(p_fetch_addr, EHCIState, 3),
> > 
> > TL;DR: I feel like we still need machine type compat properties.
> > 
> 
> I don't understand this: Could you please describe it in more detail?

See hw/core/machine.c and entries added into hw_compat_*[] arrays.  IIUC,
if this is an important device and if we want to guarantee bidirectional
migration (I'll explain later), then we should stick with machine compat
properties.

> 
> > Details:
> > 
> > When a v2 stream arrives, two _TEST()s will do the loading, then
> > post_load() extend it to 64bits, looks fine.
> > 
> > When a v3 stream arrives, two _TEST()s got skipped then latter two take effect.
> > post_load() skips.  Looks fine.
> > 
> > When migrating to another QEMU, due to the fact saving vmstates always take
> > vmsd's version declared (3), I don't see how it can migrate back to a v2 stream;
> > it didn't know about v3.
> > 
> > Jiamin, have you tested migrating from a new QEMU binary back to another
> > old one?  For upstream and serious devices, we need to guarantee
> > bi-directional migrations, back and forth.
> > 
> 
> Sorry, I am not familiar with the design of QEMU migration, and I don't know how to test it.
> I added these hook functions based on Philippe's suggestion and review.
> Could you tell me how to test migration to ensure both version 3 and version 2 are workable?

Since this patch already modified VMSDs, I believe migration test should
have been carried out at the very minimum..  Logically if vmsd versioning
is used, we should also have tested forward migrations, because that's only
for that.

What I'm talking about is I think backward migration will fail.

Forward migration describes the case when a VM hosted by an old QEMU binary
(e.g. QEMU v10.2.0) is migrated to a new QEMU (e.g., after this patch
applied on top of master).

Backward migration describes the case when a VM hosted by a new QEMU binary
(e.g., after this patch applied on top of master) is migrated back to an
old QEMU binary (e.g. QEMU v10.2.0).

For different devices, we should allow different level of support on
migration.  Any device that may be important to either upstream QEMU or
downstreams should better allow bi-directional migration.  In this case we
need to use machine compat properties I mentioned.  I'm not yet sure where
EHCI controller falls e.g. v.s. XHCI.. when not sure, we can also just
stick with machine compat properties to be on the safe side.

For more info, you can also refer to:

https://www.qemu.org/docs/master/devel/migration/compatibility.html

Thanks,

-- 
Peter Xu