Re: [PATCH v17 03/21] hw: arm: virt: rework MSI-X configuration

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Jan 27, 2026 at 02:10:08PM +0000, Peter Maydell wrote:
> On Tue, 27 Jan 2026 at 13:40, Mohamed Mediouni <mohamed@unpredictable.fr> wrote:
> >
> >
> >
> > > On 27. Jan 2026, at 13:54, Peter Maydell <peter.maydell@linaro.org> wrote:
> > >
> > > On Tue, 27 Jan 2026 at 12:46, Mohamed Mediouni <mohamed@unpredictable.fr> wrote:
> > >>> On 27. Jan 2026, at 11:54, Peter Maydell <peter.maydell@linaro.org> wrote:
> > >>>
> > >>> On Wed, 21 Jan 2026 at 13:41, Mohamed Mediouni <mohamed@unpredictable.fr> wrote:
> > >>>> +/*
> > >>>> + * In the prior Qemu ACPI table handling, GICv2 configurations
> > >>>> + * had vms->its=1... That's broken.
> > >>>> + *
> > >>>> + * Match that assumption to match the existing ACPI tables that
> > >>>> + * have been shipping for quite a while.
> > >>>> + */
> > >>>> +static int is_gicv2_acpi_workaround_needed(VirtMachineState *vms) {
> > >>>> +    return vms->gic_version == 2;
> > >>>> +}
> > >>>
> > >>> We don't need to keep identical bug-for-bug ACPI tables like that.
> > >>> If we were incorrectly reporting an ITS in a GICv2-only ACPI table,
> > >>> that was a bug and we can fix it. (This might need adjusting of the
> > >>> golden reference ACPI data in some of the bios-tables-tests if we
> > >>> were testing that, so it ought to go in its own patch.)
> > >>>
> > >> Hello,
> > >>
> > >> I’m a bit concerned about breaking hibernation in this case…
> > >>
> > >> My intent was keeping this behavior for now and then add a machine model version dependent toggle in a follow-up patch.
> > >
> > > I'm not an ACPI table expert but my understanding is that it's
> > > OK to change the ACPI table contents without having to make
> > > those changes machine-version dependent. See e.g. commit d6afe18b7242,
> > > which changed the ACPI tables for the its=off case and did not
> > > make those changes machine-version specific.
> 
> > That commit didn’t affect the default/regular config so it wouldn't have been too problematic in practice.
> >
> > Have had countless issues with how brittle hibernation is* - and more or less subtle ACPI table changes
> > tend to break it.
> 
> I don't want to add back-compat handling for this to the virt
> board unless one of our ACPI table experts says that yes we
> do need to keep the ACPI table contents identical for older
> versioned machine types.
> 
> thanks
> -- PMM


Generally what we have handles VM migration, not hybernation.  The issue
with hybernation is guests might cache some data to speed up init. If
you want to go overboard you would have to never change anything at all
in the firmware.  Whether they do it in any specific instance is hard to
predict 100% but our approach generally is to try with a couple of
popular guests, and not to worry too much ahead of time otherwise.  For
several reasons: one is most changes are harmless, another one there's
no special race here, if there's an issue you can trigger it
predictably, yet another one is hybernation is a rarely used feature.

For the specific change, I'd guess just test and if fine - fix it without a compat.

-- 
MST