> 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:
>>
>> Introduce a -M msi= argument to be able to control MSI-X support
>> independently
>> from ITS, as part of supporting GICv3 + GICv2m platforms.
>>
>> Remove vms->its as it's no longer needed after that change.
>>
>> Signed-off-by: Mohamed Mediouni <[email protected]>
>> ---
>> hw/arm/virt-acpi-build.c | 27 ++++++--
>> hw/arm/virt.c | 137 +++++++++++++++++++++++++++++++++++++--
>> include/hw/arm/virt.h | 8 ++-
>> 3 files changed, 157 insertions(+), 15 deletions(-)
>>
>> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
>> index 03b4342574..187dd4e272 100644
>> --- a/hw/arm/virt-acpi-build.c
>> +++ b/hw/arm/virt-acpi-build.c
>> @@ -440,6 +440,17 @@ static void create_rc_its_idmaps(GArray *its_idmaps,
>> GArray *smmuv3_devs)
>> }
>> }
>>
>> +/*
>> + * 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.
>> +bool virt_is_its_enabled(VirtMachineState *vms)
>> +{
>> + switch (vms->msi_controller) {
>> + case VIRT_MSI_CTRL_NONE:
>> + return false;
>> + case VIRT_MSI_CTRL_ITS:
>> + return true;
>> + case VIRT_MSI_CTRL_GICV2M:
>> + return false;
>> + case VIRT_MSI_CTRL_AUTO:
>> + /*
>> + * Earlier Qemu considered its=on as the default when using the
>> GICv2.
>> + * It is safe to do this because this is called is prior to
>> + * finalize_msi_controller.
>> + */
>> + return true;
>> + default:
>> + g_assert_not_reached();
>> + }
>> +}
>> +
>> +bool virt_is_gicv2m_enabled(VirtMachineState *vms)
>> +{
>> + switch (vms->msi_controller) {
>> + case VIRT_MSI_CTRL_NONE:
>> + return false;
>> + case VIRT_MSI_CTRL_ITS:
>> + case VIRT_MSI_CTRL_GICV2M:
>> + case VIRT_MSI_CTRL_AUTO:
>> + return !virt_is_its_enabled(vms);
>> + default:
>> + g_assert_not_reached();
>> + }
>> +}
>
> 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?
> thanks
> -- PMM
>
