[PATCH v2] ARM: DT: Add binding for GIC virtualization extentions (VGIC)

Grant Likely grant.likely at secretlab.ca
Sat May 12 01:11:28 EST 2012


On Wed, May 9, 2012 at 3:34 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On Wed, 9 May 2012 20:47:06 +0000, Arnd Bergmann <arnd at arndb.de> wrote:
>> On Wednesday 09 May 2012, Marc Zyngier wrote:
>>> Ah, I see what you mean. But these registers and interrupt are actually
>>> only visible on the hypervizor side. The guest shouldn't see any of
> this.
>>
>> Rihgt, that makes sense.
>>
>>> I suppose we could have a "arm,has-virt-extensions" property in devices
>>> that implement the virtualization extensions (GIC, timers...).
>>>
>>> What do you think?
>>
>> Sounds good. I don't have a strong preference whether that should be a
>> property like you suggest or a separate "compatible" value, maybe Rob or
>> Grant can comment on what they prefer.
>
> At the moment, the compatible string should be pretty explicit, as it is
> not possible to build an A7 or A15 based SoC without the virtualization
> extensions.
>
>> On the guest side, is it guaranteed that the virtual GIC looks like
>> a real GIC without those extensions? If the actual behavior depends on
>> the hypervisor, it might still make sense to add another flag in there
>> to tell that it's virtual, even if we don't require it for now.
>
> Nothing is really guaranteed, as the VGIC only exposes a GIC CPU interface
> to the guest, and the distributor has to be modeled by the hypervisor. But
> if the difference is observable by the guest, is it still a GIC? And how to
> differentiate between behavior A and behavior B with a single flag?
>
> My take would be that if the guest can tell the difference, than it
> shouldn't be called a GIC, and have separate bindings. Or at least a
> different compatible string that we could use to enable quirks in the
> driver.

I would agree with that.

g.


More information about the devicetree-discuss mailing list