From: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
To: Jeremy Kerr <jk@ozlabs.org>, 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, 3 Oct 2019 10:21:12 +0530 [thread overview]
Message-ID: <0e8a4057-fbe7-9b1a-6613-ad500ebe8b67@linux.vnet.ibm.com> (raw)
In-Reply-To: <2bb75b409a1159d5524be2d661e548e32fed152e.camel@ozlabs.org>
On 10/3/19 7:17 AM, Jeremy Kerr wrote:
> Hi Vasant,
Jeremy,
>
>> Add check to validate whether requested page is part of system RAM
>> or not before mmap() and error out if its not part of system RAM.
>
> opal_prd_range_is_valid() will return false if the reserved memory range
> does not have an ibm,prd-label property. If this you're getting invalid
> memory mapped through the PRD interface, that means the device tree is
> incorrectly describing those ranges.
Correct. We will have `ibm,prd-label` property. That's not the issue. Here issue
is HBRT is loaded into NVDIMM memory.
Copy-pasting Vaidy's explanation from internal bugzilla here:
------------------
The root-cause of the problem seem to be in HBRT using NVDIMM area/addresses for
firmware operation.
Linux maps the required address for HBRT to read, write and execute. This all
works fine for normal RAM addresses. However NVDIMM is not normal RAM, it is
device memory which can be used as RAM or through other layers and subsystem.
Linux kernel memory manager set page table attributes as 0b10 non-idempotent I/O
instead of normal RAM 0b00 since this is a special type of device memory
initialized and used by a firmware device driver. This prevented instruction
execution from that mapped page. Since instruction could not be fetched,
opal-prd application could not complete init and start.
------------------
Hostboot should detect NVDIMM areas and avoid using those areas for any firmware
purposes including HBRT. Hostboot will fix this issue.
In this patch we are adding additional check to make sure mmap() fails
gracefully and we log proper error log. That way opal-prd will fail to start
instead of looping forever .
-Vasant
next prev parent reply other threads:[~2019-10-03 4:53 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 [this message]
2019-10-03 4:56 ` Jeremy Kerr
2019-10-03 5:31 ` Vasant Hegde
2019-10-03 7:07 ` Jeremy Kerr
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=0e8a4057-fbe7-9b1a-6613-ad500ebe8b67@linux.vnet.ibm.com \
--to=hegdevasant@linux.vnet.ibm.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=jk@ozlabs.org \
--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).