> 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.
>
Hi,
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.
* and Qemu doesn’t provide an FACS (nevermind one with an HW signature) to
force a clean reboot
- which Windows ignores anyway
>>>> +bool virt_is_its_enabled(VirtMachineState *vms)
>
>>> Why do we need these? The idea of finalize_msi_controller()
>>> is that it fixes vms->msi_controller so that you can just
>>> directly say vms->msi_controller == VIRT_MSI_CTRL_ITS or
>>> vms->msi_controller == VIRT_MSI_CTRL_GICV2M rather than
>>> having to have more complicated logic.
>>>
>> It’s because of object_class_property_add_str(oc, "msi", virt_get_msi,
>> virt_set_msi) (and the same applies for the its property), is it safe to
>> assume that virt_get_msi/virt_get_its will never be called from that prior
>> to finalize?
>
> The get and set property functions need to handle the
> msi_controller field not having been finalized, but
> they are only getting and setting it.
>
> thanks
> -- PMM
>
