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 3/3] KVM: ARM: Add support for Cortex-A7
Date: Thu, 26 Sep 2013 17:50:23 +0100	[thread overview]
Message-ID: <524465CF.4020401@arm.com> (raw)
In-Reply-To: <20130926161743.GD1389@cbox>

On 26/09/13 17:17, Christoffer Dall wrote:
> On Thu, Sep 26, 2013 at 04:49:28PM +0100, Jonathan Austin wrote:
>> This patch adds support for running Cortex-A7 guests on Cortex-A7 hosts.
>>
>> As Cortex-A7 is architecturally compatible with A15, this patch is largely just
>> generalising existing code. Areas where 'implementation defined' behaviour
>> is identical for A7 and A15 is moved to allow it to be used by both cores.
>>
>> The check to ensure that coprocessor register tables are sorted correctly is
>> also moved in to 'common' code to avoid each new cpu doing its own check
>> (and possibly forgetting to do so!)
>>
>> Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
>> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
> 
> The patch itself looks good, I'm wondering if we are creating potential
> confusion by not having a separate table for shared, but implementation
> defined, co-processors.  One option would be to have multiple levels of
> 'inheritance' of the the coprocessor table, so you could load the
> generic one, overload it with the a15 one, and then overload it with the
> a7 one.  That may be a bit over-engineerd though.

So my take on this is that it is OK to have default implementation
defined at the generic level, as long as the handling is "benign
enough". The core-specific code can always override it with something
more fun.

> Then again, if A7/A15 end up being just two cores out of many many more,
> it's a bit weird to have their register definitions in the coproc.c
> files and everyone elses in their own files, sort of pushing the problem
> under the rug.
> 
> Unless of course we just agree that there are probably not going to be
> that many cores and they're all just going to look a lot like each other
> wrt. to the impdef registers anyhow, so it makes sense to provide this
> default implementation...

There will probably be some Cortex-A12 code at one point, but I cannot
foresee massive changes, as it is supposed to be fairly similar to both
A7 and A15.

> If nobody else objects, I'm ok with merging this code (once I have a
> chance to test it).  We can always add more logic and move things around
> later, as there's no api breakage or anything like that.

Sounds good to me.

	M.
-- 
Jazz is not dead. It just smells funny...

  reply	other threads:[~2013-09-26 16:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-26 15:49 [PATCH 0/3] KVM: ARM: Cortex-A7 support and fixes Jonathan Austin
2013-09-26 15:49 ` [PATCH 1/3] KVM: ARM: fix the size of TTBCR_{T0SZ,T1SZ} masks Jonathan Austin
2013-09-26 16:07   ` Christoffer Dall
2013-09-26 15:49 ` [PATCH 2/3] KVM: ARM: Fix calculation of virtual CPU ID Jonathan Austin
2013-09-26 16:12   ` Christoffer Dall
2013-09-26 15:49 ` [PATCH 3/3] KVM: ARM: Add support for Cortex-A7 Jonathan Austin
2013-09-26 16:17   ` Christoffer Dall
2013-09-26 16:50     ` Marc Zyngier [this message]
2013-09-26 17:09     ` Jonathan Austin
     [not found]       ` <CA+eFSM1YdhBDMAvyXknMA62Ao3CEntMptdi7RD=NXis1F-BmfQ@mail.gmail.com>
2013-10-06 14:56         ` Peter Maydell
     [not found]           ` <CA+eFSM0k3mA4uOiEvmE_tfVjnpq8DpXV-=nJXhucUDePJRTYXw@mail.gmail.com>
2013-10-07  8:07             ` Marc Zyngier
2013-10-07  9:17               ` Gavin Guo
2013-10-07  9:29                 ` Marc Zyngier
2013-10-09 13:06           ` Diana Craciun
2013-10-08 14:16 ` [PATCH 0/3] KVM: ARM: Cortex-A7 support and fixes Gavin Guo
2013-10-09  9:21   ` Jonathan Austin
2013-10-16  0:25 ` Christoffer Dall

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=524465CF.4020401@arm.com \
    --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).