> 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?
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.

Thanks,
> thanks
> -- PMM


Reply via email to