Re: [RFC PATCH-for-9.1? 1/2] target/arm: Move qmp_query_gic_capabilities() to hw/intc/

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Aug 08, 2024 at 11:15:17AM +0100, Peter Maydell wrote:
> On Thu, 8 Aug 2024 at 10:02, Markus Armbruster <armbru@redhat.com> wrote:
> >
> > Peter Maydell <peter.maydell@linaro.org> writes:
> >
> > > On Thu, 8 Aug 2024 at 05:32, Markus Armbruster <armbru@redhat.com> wrote:
> > >>
> > >> Peter Maydell <peter.maydell@linaro.org> writes:
> > >>
> > >> [...]
> > >>
> > >> > The QAPI command which this code is implementing is
> > >> > also (a) target-specific and (b) unfortunately
> > >> > designed so that it doesn't get passed a particular
> > >> > CPU or particular device to query, it's just assumed
> > >> > to be a part of the whole simulation.
> > >>
> > >> We can fix (b) if we care: add a suitable optional argument, default to
> > >> the sole GIC in the system, fail if there's more than one.  I assume we
> > >> have no machines with more than one now.
> > >
> > > The exynos4210 SoC (board types 'nuri', 'smdkc210') has
> > > two GICs. (It's a rather odd design -- there's the
> > > interrupt controller that's part of the main CPU
> > > cluster, and then they used a second "external" GIC
> > > that feeds into that one.)
> >
> > Then "fail if there's more than one" would be an incompatible change for
> > this machine.
> >
> > If the two GICs have identical capabilities, it doesn't matter to which
> > of the two query-gic-capabilities technically applies.
> >
> > Else, it matters, and we have an interface issue.  Do we?
> 
> It's not possible to use KVM with that machine type, so the
> question is a bit moot. (This also indicates that the
> interface is not very helpful -- it purports to tell the
> management layer whether it can use an accelerated in-kernel
> GIC, but because it doesn't specifiy the board type there's
> no way to provide an accurate answer. It would be useful
> to know exactly what libvirt/etc actually use this for...)

Libvirt uses this exclusively with the arm 'virt' machine type.

If the user didn't express any GIC preference, then if KVM is in use,
we'll pick the highest GIC version QEMU reports as supported. If TGCG
is in use we'll always pick v2, even if QEMU reports v3 is emulatable
due to the v3 impl lacking MSI controller which we need for PCI-e

  https://gitlab.com/libvirt/libvirt/-/blob/master/src/qemu/qemu_domain.c#L4456

We'll also report to mgmt apps what GIC versions are available.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|