Re: detecting the GIC version in the host and in the guest

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Cheers,
Andre.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm




[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux