Hi Drew, On 1/31/22 5:14 PM, Andrew Jones wrote: > On Mon, Jan 31, 2022 at 04:05:06PM +0000, Peter Maydell wrote: >> On Mon, 31 Jan 2022 at 15:59, Andrew Jones <[email protected]> wrote: >>> Hmm, if these machine types completely depend on userspace gicv3 >>> emulation, i.e. no way to use in-kernel gic or another tcg gic >>> model, then I guess they shouldn't be built at all when ARM_GIC_TCG >>> isn't configured. I.e. >>> >>> diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig >>> index 2e0049196d6c..d7cc028b049d 100644 >>> --- a/hw/arm/Kconfig >>> +++ b/hw/arm/Kconfig >>> @@ -209,6 +209,7 @@ config REALVIEW >>> >>> config SBSA_REF >>> bool >>> + depends on ARM_GIC_TCG >>> imply PCI_DEVICES >>> select AHCI >>> select ARM_SMMUV3 >>> @@ -378,6 +379,7 @@ config XLNX_ZYNQMP_ARM >>> >>> config XLNX_VERSAL >>> bool >>> + depends on ARM_GIC_TCG >>> select ARM_GIC >>> select PL011 >>> select CADENCE >> I kind of agree, but isn't this kind of mixing two things? > How about two dependencies? > >> (1) Both these machines require a GICv3 and a GICv2 won't do, >> so they should do something that says "if you want this >> machine type, you need a GICv3 device" > depends on ARM_GIC_TCG (IMO, could use a rename to be gicv3 specific) Yep I think it would be clearer to rename the CONFIG. > >> (2) Both these machines don't work with KVM or hvf, so if we're >> not building TCG then there's no point configuring in these >> machine models (a property they share with every other arm >> machine type except "virt", currently) > depends on TCG
That's what I would be inclined to do as well Thanks Eric > > Thanks, > drew >
