linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Jeremy Kerr <jk@ozlabs.org>
To: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>, linuxppc-dev@ozlabs.org
Cc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>,
	"Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>
Subject: Re: [PATCH] powerpc/powernv/prd: Validate whether address to be mapped is part of system RAM
Date: Thu, 03 Oct 2019 15:07:24 +0800	[thread overview]
Message-ID: <452718dfe591c4718498aab6b5c7b68a95cf6c5a.camel@ozlabs.org> (raw)
In-Reply-To: <9b9b529d-cad7-0ace-acf6-e07d0dea5670@linux.vnet.ibm.com>

Hi Vasant,

> > OK. How about we just don't do that?
> 
> Yes. Hostboot will fix that. It will make sure that HBRT is loaded
> into regular memory.

Super.

> > It sounds like we're just trying to work around an invalid
> > representation of the mappings.
> 
> Its not workaround. Its additional check.

The issue is that you've added a check for stuff that the kernel doesn't
(and shouldn't) know about, and assumed that the kernel knows better
than the device tree. It may be the correct thing to do in this case,
but we can't guarantee that it's always correct.

For example, what if there is a future HBRT range that is fine to go
into NVRAM? With this change, that's not possible.

Or, what if there's a range of address-space that isn't backed by system
RAM (say, some MMIO-mapped hardware) that we want to expose to a future
HBRT implementation? This change will block that.

The kernel doesn't know what is and is not valid for a HBRT mapping, so
it has no reason to override what's specified in the device tree. We've
designed this so that the kernel provides the mechanism for mapping
pages, and not the policy of which pages can be mapped.

Regards,


Jeremy



  reply	other threads:[~2019-10-03  7:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-02  7:48 [PATCH] powerpc/powernv/prd: Validate whether address to be mapped is part of system RAM Vasant Hegde
2019-10-02  8:48 ` Vaidyanathan Srinivasan
2019-10-03  1:47 ` Jeremy Kerr
2019-10-03  4:51   ` Vasant Hegde
2019-10-03  4:56     ` Jeremy Kerr
2019-10-03  5:31       ` Vasant Hegde
2019-10-03  7:07         ` Jeremy Kerr [this message]
2019-10-03 10:29           ` Vaidyanathan Srinivasan
2019-10-04  3:27             ` Jeremy Kerr
2019-10-05  5:08               ` Vaidyanathan Srinivasan

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=452718dfe591c4718498aab6b5c7b68a95cf6c5a.camel@ozlabs.org \
    --to=jk@ozlabs.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=hegdevasant@linux.vnet.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=svaidy@linux.vnet.ibm.com \
    /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).