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 20 October 2014 16:03, Claudio Fontana <claudio.fontana at huawei.com> 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?

-- PMM

Hello,
maybe I should have added that I am looking at AArch64 only, and that the long term plan is to move from device trees to ACPI for the guest as well.

ACPI 5.1 provides as far as I understand extended support for the GIC, including the address of the GIC distributor and CPU interface;
but I wondered however how to reliably query the supported GIC version. Maybe there is not an agreed way to do it yet.
For the server use case in the long term, device trees, non-discoverable devices and specialized vendor-specific image builds are not feasible I am afraid.

Thanks,

Claudio

_______________________________________________
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