> On 27. Jan 2026, at 16:34, Michael S. Tsirkin <[email protected]> wrote:
>
> On Tue, Jan 27, 2026 at 02:10:08PM +0000, Peter Maydell wrote:
>> On Tue, 27 Jan 2026 at 13:40, Mohamed Mediouni <[email protected]>
>> wrote:
>>>
>>>
>>>
>>>> On 27. Jan 2026, at 13:54, Peter Maydell <[email protected]> wrote:
>>>>
>>>> On Tue, 27 Jan 2026 at 12:46, Mohamed Mediouni <[email protected]>
>>>> wrote:
>>>>>> On 27. Jan 2026, at 11:54, Peter Maydell <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>> On Wed, 21 Jan 2026 at 13:41, Mohamed Mediouni
>>>>>> <[email protected]> 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.
>
Hi,
It turns out that even the Ubuntu stock kernel of all things has hibernation
disabled on arm64.
Had to install the linux-aws variant to test it and that testing didn’t go too
well without even making
any Qemu changes between suspend and resume.
So considering it as unimportant…
(And just sent a new rev with putting the new behaviour, had to tackle a bug on
the way)
Thank you,
-Mohamed
> --
> MST
>
>
