From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Michael Ellerman <mpe@ellerman.id.au>,
Christoph Hellwig <hch@infradead.org>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: Cameron Berkenpas <cam@neo-zeon.de>, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc/mm/book3s64/hash: Update 4k PAGE_SIZE kernel mapping
Date: Thu, 17 Oct 2019 13:18:47 +1100 [thread overview]
Message-ID: <c572c8f6badae4fcd961114ba38942afe89252ca.camel@kernel.crashing.org> (raw)
In-Reply-To: <87ftjtt4uw.fsf@mpe.ellerman.id.au>
On Wed, 2019-10-16 at 20:30 +1100, Michael Ellerman wrote:
> I think the main reason is that in some configurations we can't use 64K
> pages for MMIO, so the 64K vmalloc mappings and 4K MMIO mappings need to
> be in different segments.
>
> It's possible that's no longer true on modern configs. But annoyingly I
> can't easily tell because the kernel doesn't know, it defers to firmware
> telling it via the "ibm,pa-features" property and setting
> MMU_FTR_CI_LARGE_PAGE.
>
> The spec (PAPR) doesn't give us any hints either it just says the bit in
> the device tree means:
>
> The value of 1 indicates support for I=1 (cache inhibited) large
> pages; else not supported.
>
> Which at least suggests that firmware is allowed to support 64K MMIO
> mappings or not at its whim.
>
> Hopefully Ben or Paul remember more details than me.
Not 100% certain but I think the HW only started supporting non-4k MMIO
pages with P7 (or was it some variant of P6 ?)
Also it's unclear under what circumstances the proprietary hypervisor
or KVM will allow it. I know at some point KVM didn't...
Cheers,
Ben.
next prev parent reply other threads:[~2019-10-17 2:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-16 5:51 [PATCH] powerpc/mm/book3s64/hash: Update 4k PAGE_SIZE kernel mapping Aneesh Kumar K.V
2019-10-16 6:05 ` Christoph Hellwig
2019-10-16 8:45 ` Aneesh Kumar K.V
2019-10-16 9:30 ` Michael Ellerman
2019-10-17 2:18 ` Benjamin Herrenschmidt [this message]
2019-10-16 16:21 ` Cameron Berkenpas
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=c572c8f6badae4fcd961114ba38942afe89252ca.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=cam@neo-zeon.de \
--cc=hch@infradead.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.