linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] ARM: DT: Add binding for GIC virtualization extentions (VGIC)
Date: Wed, 09 May 2012 22:42:05 +0200	[thread overview]
Message-ID: <37e096905f891fc6abdccf8977bd7447@localhost> (raw)
In-Reply-To: <201205092027.50059.arnd@arndb.de>

On Wed, 9 May 2012 20:27:49 +0000, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 09 May 2012, Marc Zyngier wrote:
>> On Wed, 9 May 2012 19:21:42 +0000, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Wednesday 09 May 2012, Marc Zyngier wrote:
>> >> 
>> >> The GICv2 can have virtualization extension support, consisting
>> >> of an additional set of registers and interrupts. Add the necessary
>> >> binding to the GIC DT documentation.
>> >> 
>> >> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> > 
>> > Would it make sense to add a way to detect whether a GIC is virtual
>> > or real? Maybe an optional empty "virtual-gic" property or an
>> > additional
>> > "compatible" value. Even if we don't need it now, it might come in
>> > handy
>> > if we require it already.
>> 
>> I don't really see a need for this. When running on a virtual machine,
>> the
>> kernel cannot tell if this is the real thing or not (the virtual CPU
>> interface looks exactly like the normal one once mapped into the guest
>> address space).
>> 
>> Or maybe I just didn't get your use case?
> 
> Well, one difference seems to be the VGIC maintainance interrupt that
may
> or may not be present, and another one the additional registers. Of
course
> you can imply the type of GIC from the presence of this extra data,
> but I think it would be better to make it explicit.

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.

I suppose we could have a "arm,has-virt-extensions" property in devices
that implement the virtualization extensions (GIC, timers...).

What do you think?

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

  reply	other threads:[~2012-05-09 20:42 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
2012-05-09 19:21 ` Arnd Bergmann
2012-05-09 19:36   ` Marc Zyngier
2012-05-09 20:27     ` Arnd Bergmann
2012-05-09 20:42       ` Marc Zyngier [this message]
2012-05-09 20:47         ` Arnd Bergmann
2012-05-09 21:34           ` Marc Zyngier
2012-05-10 10:53             ` Arnd Bergmann
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
2012-05-11 14:43     ` David Vrabel
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=37e096905f891fc6abdccf8977bd7447@localhost \
    --to=marc.zyngier@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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).