On Wed, May 9, 2012 at 3:34 PM, Marc Zyngier <[email protected]> wrote: > On Wed, 9 May 2012 20:47:06 +0000, Arnd Bergmann <[email protected]> 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. _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
