Hi Wei, On Tue, Oct 21 2014 at 04:35:38 PM, Wei Huang <wei@xxxxxxxxxx> wrote: > 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. If you had a chance to read the architecture document (it is unfortunately not public yet), you'd quickly notice that the similarity between GICv2 and GICv3 is fairly superficial, specially in the absence of the GICv2 compatibility regions (they are optional). We have DT/ACPI/whatever for this exact purpose: finding out what the hardware is. These mechanisms give us structured information that describe the available HW in great detail, and I will strongly oppose any form of guess-work. Sorry, but I have to ask: what is wrong with the current DT parsing? Thanks, M. -- Jazz is not dead. It just smells funny. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
