From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene
Date: Mon, 23 Feb 2015 13:07:44 +0100 [thread overview]
Message-ID: <20150223120744.GA5609@cbox> (raw)
In-Reply-To: <CAL_JsqLcBOC+AnVe7oATjg2g6Fz2vqwacu8QzS4tXMaxxOP_Xg@mail.gmail.com>
On Sat, Feb 21, 2015 at 03:56:17PM -0600, Rob Herring wrote:
> On Thu, Feb 19, 2015 at 1:03 PM, Christoffer Dall
> <christoffer.dall@linaro.org> wrote:
> > On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote:
> >> On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar
> >> <psawargaonkar@apm.com> wrote:
> >> > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned
> >> > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page
> >> > size due to size alignment checking in vgic driver for VCPU Control and
> >> > VCPU register.
> >> >
> >> > This patch corrects the sizes to be inline with the hardware spec.
> >>
> >> This does not make sense. The GIC regions are still only 4 or 8KB and
> >> the h/w description should reflect that. For implementations using
> >> gic-400 and the addressing decode trick, the rest of the register
> >> range is also not safe to access given it is multiple mapped. Also,
> >> this wastes virtual space, but I guess we don't care on 64-bit.
> >>
> >> KVM should be fixed to only check base address alignment. Size
> >> alignment does not matter (if it does, then you need to fix all
> >> register blocks).
> >>
> > It matters if you want to ensure that the 64K page you are assigning to
> > a guest for the GIC virtual CPU interface contains only GIC virtual CPU
> > mappings, and not other random stuff that the guest is not allowed to
> > touch.
>
> Good point.
>
> > How else should this be enforced?
>
> Rely on correct h/w design? You'll have to repeat this every time you
> want to do pass-thru of a device.
>
> What do you do if 64K mapping is not supported? Fallback to emulation
> of the CPU interface?
Agree with Peter on these two points.
>
> Are there other DTSs that need to be fixed?
>
Not sure really, AMD Seattle works with 64K pages IIRC.
Thanks,
-Christoffer
next prev parent reply other threads:[~2015-02-23 12:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-27 7:03 [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene Pranavkumar Sawargaonkar
2015-01-27 9:32 ` Jon Masters
2015-02-11 4:09 ` Pranavkumar Sawargaonkar
2015-02-19 15:51 ` Christoffer Dall
2015-02-19 18:23 ` Rob Herring
2015-02-19 19:03 ` Christoffer Dall
2015-02-21 21:56 ` Rob Herring
2015-02-21 23:58 ` Peter Maydell
2015-02-23 12:07 ` Christoffer Dall [this message]
2015-02-23 12:24 ` Jon Masters
2015-02-23 16:39 ` Rob Herring
2015-02-24 6:34 ` Pranavkumar Sawargaonkar
2015-02-24 14:30 ` Rob Herring
2015-02-27 3:57 ` Pranavkumar Sawargaonkar
2015-03-19 18:54 ` Marc Zyngier
2015-03-11 14:53 ` Marc Zyngier
2015-03-11 17:19 ` Feng Kan
2015-03-11 17:31 ` Marc Zyngier
2015-03-11 17:57 ` Feng Kan
2015-03-11 18:17 ` Marc Zyngier
2015-03-12 3:52 ` Pranavkumar Sawargaonkar
2015-03-12 9:25 ` Marc Zyngier
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=20150223120744.GA5609@cbox \
--to=christoffer.dall@linaro.org \
--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).