Nathan Lynch <nath...@linux.ibm.com> writes: > Michael Ellerman <m...@ellerman.id.au> writes: >> Nathan Lynch <nath...@linux.ibm.com> writes: >>> Memory locations passed as arguments from the OS to RTAS usually need >>> to be addressable in 32-bit mode and must reside in the Real Mode >>> Area. On PAPR guests, the RMA starts at logical address 0 and is the >>> first logical memory block reported in the LPAR’s device tree. >>> >>> On powerpc targets with RTAS, Linux makes available to user space a >>> region of memory suitable for arguments to be passed to RTAS via >>> sys_rtas(). This region (rtas_rmo_buf) is allocated via the memblock >>> API during boot in order to ensure that it satisfies the requirements >>> described above. >>> >>> With radix MMU, the upper limit supplied to the memblock allocation >>> can exceed the bounds of the first logical memory block, since >>> ppc64_rma_size is ULONG_MAX and RTAS_INSTANTIATE_MAX is 1GB. >> >> Why does the size of the first memory block matter for radix? > > Here is my understanding: in the platform architecture, the size of the > first memory block equals the RMA, regardless of the MMU mode. It just > so happens that when using radix, Linux can pass ibm,configure-connector > a work area address outside of the RMA because the allocation > constraints for the work area are computed differently. It would be > wrong of the OS to pass RTAS arguments outside of this region with hash > MMU as well.
If that's the requirement then shouldn't we be adjusting ppc64_rma_size? Otherwise aren't other uses of ppc64_rma_size going to run into similar problems. Or does the RMA only apply for RTAS calls when using radix? cheers
