> On 27. Oct 2025, at 17:03, Peter Maydell <[email protected]> wrote:
>
> On Thu, 2 Oct 2025 at 05:30, Mohamed Mediouni <[email protected]>
> wrote:
>>
>>
>>
>>> On 25. Sep 2025, at 18:24, Peter Maydell <[email protected]> wrote:
>>>
>>> On Sat, 20 Sept 2025 at 15:02, Mohamed Mediouni
>>> <[email protected]> wrote:
>>>>
>>>> On Hypervisor.framework for macOS and WHPX for Windows, the provided
>>>> environment is a GICv3 without ITS.
>>>>
>>>> As such, support a GICv3 w/ GICv2m for that scenario.
>>>>
>>>> Signed-off-by: Mohamed Mediouni <[email protected]>
>>>>
>>>> Reviewed-by: Pierrick Bouvier <[email protected]>
>>>> ---
>>>> hw/arm/virt-acpi-build.c | 4 +++-
>>>> hw/arm/virt.c | 8 ++++++++
>>>> include/hw/arm/virt.h | 2 ++
>>>> 3 files changed, 13 insertions(+), 1 deletion(-)
>>>
>>> Looking at this I find myself wondering whether we need the
>>> old-version back compat handling. The cases I think we have
>>> at the moment are:
>>>
>>> (1) TCG, virt-6.1 and earlier: no_tcg_its is set
>>> -- you can have a gicv2 (always with a gicv2m)
>>> -- if you specify gic-version=3 you get a GICv3 without ITS
>>> (2) TCG, virt-6.2 and later:
>>> -- gic-version=2 still has gicv2m
>>> -- gic-version=3 by default gives you an ITS; if you also
>>> say its=off you get GICv3 with no ITS
>>> -- there is no case where we provide a GICv3 and are
>>> unable to provide an ITS for it
>>> (3) KVM (any version):
>>> -- gic-version=2 has a gicv2m
>>> -- gic-version=3 gives you an ITS by default; its=off
>>> will remove it
>>> -- there is no case where we provide a GICv3 and are
>>> unable to provide an ITS for it
>>> (4) HVF:
>>> -- only gic-version=2 works, you get a gicv2m
>>>
>>> and I think what we want is:
>>> (a) if you explicitly disable the ITS (with its=off or via
>>> no_tcg_its) you get no ITS (and no gicv2m)
>>> (b) if you explicitly enable the ITS you should get an
>>> actual ITS or an error message
>>> (c) the default should be its=auto which gives
>>> you "ITS if we can, gicv2m if we can't".
>>> This is repurposing the its= property as "message signaled
>>> interrupt support", which is a little bit of a hack
>>> but I think OK if we're clear about it in the docs.
>>> (We could rename the property to "msi=(off,its,gicv2m,auto)"
>>> with back-compat support for "its=" but I don't know if
>>> that's worth the effort.)
>>>
>>> And then that doesn't need any back-compat handling for pre-10.2
>>> machine types or a "no_gicv3_with_gicv2m" flag, because for
>>> 10.1 and earlier there is no case that currently works and
>>> which falls into category (c) and which doesn't give you an ITS.
>>> (because we don't yet have hvf gicv3 implemented: that's a new
>>> feature that never worked in 10.1.)
>>>
>>> What do you think?
>>
>> Would it be wanted to provide MSI-X support in all scenarios
>> even with its=off?
>
> We should prefer to provide MSI-X support. If the user
> explicitly asks for a config that doesn't give MSI-X
> support, that's their choice to make.
>
>> And there’s the consequence of that making GICv3 + GICv2m only
>> testable with auto and not with TCG or kvm, which doesn’t sound ideal.
>
> I guess that would be an argument for the "give the property
> the right name so we can say "msi=(off,its,gicv2m,auto)". Then
> you could say
> -accel tcg -machine gic-version=3,msi=gicv2m
>
> to test that setup.
Is there guidance around renaming properties?
Would it be proper to do:
- if its=auto, consider the new msi property
- otherwise, use the its property
Thank you,
-Mohamed
> thanks
> -- PMM
>
