On Thu, 8 Aug 2024 at 10:02, Markus Armbruster <arm...@redhat.com> wrote: > > Peter Maydell <peter.mayd...@linaro.org> writes: > > > On Thu, 8 Aug 2024 at 05:32, Markus Armbruster <arm...@redhat.com> wrote: > >> > >> Peter Maydell <peter.mayd...@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...) thanks -- PMM
