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. thanks -- PMM
