devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>
To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org,
	rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH v2] ARM: DT: Add binding for GIC virtualization extentions (VGIC)
Date: Wed, 09 May 2012 23:34:23 +0200	[thread overview]
Message-ID: <ed0ce2390716adbfc949f86c16dab996@localhost> (raw)
In-Reply-To: <201205092047.06852.arnd-r2nGTMty4D4@public.gmane.org>

On Wed, 9 May 2012 20:47:06 +0000, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> 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.

        M.
-- 
Fast, cheap, reliable. Pick two.

  parent reply	other threads:[~2012-05-09 21:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-09 17:57 [PATCH v2] ARM: DT: Add binding for GIC virtualization extentions (VGIC) Marc Zyngier
     [not found] ` <1336586277-28454-1-git-send-email-marc.zyngier-5wv7dgnIgG8@public.gmane.org>
2012-05-09 19:21   ` Arnd Bergmann
2012-05-09 19:36     ` Marc Zyngier
2012-05-09 20:27       ` Arnd Bergmann
     [not found]         ` <201205092027.50059.arnd-r2nGTMty4D4@public.gmane.org>
2012-05-09 20:42           ` Marc Zyngier
2012-05-09 20:47             ` Arnd Bergmann
     [not found]               ` <201205092047.06852.arnd-r2nGTMty4D4@public.gmane.org>
2012-05-09 21:34                 ` Marc Zyngier [this message]
2012-05-10 10:53                   ` Arnd Bergmann
     [not found]                     ` <201205101053.09954.arnd-r2nGTMty4D4@public.gmane.org>
2012-05-10 11:11                       ` Marc Zyngier
2012-05-11 15:11                   ` Grant Likely
2012-05-11 15:10                 ` Grant Likely
2012-05-11 14:14 ` David Vrabel
2012-05-11 14:42   ` Marc Zyngier
     [not found]     ` <4FAD255A.4080504-5wv7dgnIgG8@public.gmane.org>
2012-05-11 14:43       ` David Vrabel
     [not found]         ` <4FAD25A1.2080106-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
2012-05-11 15:15           ` Grant Likely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ed0ce2390716adbfc949f86c16dab996@localhost \
    --to=marc.zyngier-5wv7dgnigg8@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).