Alexey Kardashevskiy <a...@ozlabs.ru> writes: > On 15/01/2021 09:00, Nathan Lynch wrote: >> 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. (512MB is >> a common size of the first memory block according to a small sample of >> LPARs I have checked.) This leads to failures when user space invokes >> an RTAS function that uses a work area, such as >> ibm,configure-connector. >> >> Alter the determination of the upper limit for rtas_rmo_buf's >> allocation to consult the device tree directly, ensuring placement >> within the RMA regardless of the MMU in use. > > Can we tie this with RTAS (which also needs to be in RMA) and simply add > extra 64K in prom_instantiate_rtas() and advertise this address > (ALIGH_UP(rtas-base + rtas-size, PAGE_SIZE)) to the user space? We do > not need this RMO area before that point.
Can you explain more about what advantage that would bring? I'm not seeing it. It's a more significant change than what I've written here. Would it interact well with kexec? > And probably do the same with per-cpu RTAS argument structures mentioned > in the cover letter? I don't think so, since those need to be allocated with the pacas and limited to the maximum possible CPUs, which is discovered by the kernel much later. But maybe I misunderstand what you're suggesting.
