On 10/21/2014 04:21 AM, Andre Przywara wrote: > On 21/10/14 09:36, Andre Przywara wrote: >> Hi Claudio, >> >> On 20/10/14 16:10, Peter Maydell wrote: >>> On 20 October 2014 16:03, Claudio Fontana <claudio.fontana@xxxxxxxxxx> wrote: >>>> I am facing the (long term) issue of having to detect the GIC version in the host and in the kvm guest (OSv); >>>> at the moment we minimally support GICv2 in the guest, but I'd like to make the code a bit better by detecting the GIC version in the guest, >>>> and in the future optionally adapt the functionality to what is available (GICv2, GICv2m, GICv3, ...) >>>> >>>> I know that the information could be taken from the device tree, and this is what I am going for in the short term, >>>> but eventually we need to be able to discover this without preconfigured information >>>> (thus being able to use the same images on multiple systems without having to provide additional external information). >>> >>> Given that you don't even know where the GIC registers >>> are in memory (or if you should be using cp15 registers >>> instead) without the device tree, what's the problem >>> with finding the GIC version in the dtb as well as where >>> it is in memory? >> >> To answer your actual question: ;-) >> Each GIC specifies ID registers, from which you can read the GIC >> version. Unfortunately their offset is version specific :-( >> >> So assuming that you know (or can discover) where the GIC resides in >> memory, look for GICD_[CP]IDRn in the spec. Linux checks this, too: >> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/irqchip/irq-gic-v3.c#n340 >> >> If you know that you have a GICv3(sic!) and you know that SRE is enabled >> for your current EL (or can cope with the exception), you can also query >> the GICC_IIDR, which is a system register with a fixed number. >> GICv2 has something similar called ICPIDR2, but since it's memory mapped >> only, if not of much value for your purpose. >> >> So your best bet is probably some heuristics paired with clever >> exception handling in case you trap on undefined memory locations. > > Just to put that straight: I don't seriously recommend this method, this > is just as close as you could get with the GIC. As it stands (and other > have stated before), there is no safe way of detecting a GIC and it's > resources by probing or discovery, you have to have some knowledge about > how and where it's wired in your SoC. Hi Andre, For the convenience of other kernel components, is there anyway to merge *parts* of GICv2 and GICv3 at high-level? So others can probe/poke the GIC details in the system, which includes the version of GIC. For instance, I am working a patch to get rid of DT-ACPI in virt/kvm/arm/vgic.c file and facing a similar issue as described by Claudio. Current vgic.c parses DT-tree then dispatches to vgic-v2.c and vgic-v3.c. Getting rid of DT will make dispatching impossible (a dilemma). The version info provided by GIC drivers will be helpful for this case, at least. -Wei > > Cheers, > Andre. > _______________________________________________ > kvmarm mailing list > kvmarm@xxxxxxxxxxxxxxxxxxxxx > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
