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
