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

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

 



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.

Regards,
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