All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Lynch <nathanl@linux.ibm.com>
To: Michael Ellerman <mpe@ellerman.id.au>, linuxppc-dev@lists.ozlabs.org
Cc: aik@ozlabs.ru, tyreld@linux.ibm.com, brking@linux.ibm.com,
	ajd@linux.ibm.com, aneesh.kumar@linux.ibm.com
Subject: Re: [PATCH 6/6] powerpc/rtas: constrain user region allocation to RMA
Date: Tue, 19 Jan 2021 15:00:48 -0600	[thread overview]
Message-ID: <874kjcy73z.fsf@linux.ibm.com> (raw)
In-Reply-To: <87mtx5qp1g.fsf@mpe.ellerman.id.au>

Michael Ellerman <mpe@ellerman.id.au> writes:
> Nathan Lynch <nathanl@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.

> The 1GB limit is sufficient to make it accessible by 32-bit code.

But the requirement is that memory arguments passed to RTAS reside in
the RMA, which may be less than 1GB.


>> (512MB is a common size of the first memory block according to a small sample of
>> LPARs I have checked.)
>
> That's the minimum we request, see prom_init.c:
>
> 	/* option vector 2: Open Firmware options supported */
> 	.vec2 = {
> 		.byte1 = OV2_REAL_MODE,
> 		.reserved = 0,
> 		.real_base = cpu_to_be32(0xffffffff),
> 		.real_size = cpu_to_be32(0xffffffff),
> 		.virt_base = cpu_to_be32(0xffffffff),
> 		.virt_size = cpu_to_be32(0xffffffff),
> 		.load_base = cpu_to_be32(0xffffffff),
> 		.min_rma = cpu_to_be32(512),		/* 512MB min RMA */
>
> Since v4.12 in 2017.

Thanks for the pointer, I had been trying to find this without success.

  reply	other threads:[~2021-01-19 21:02 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-14 21:59 [PATCH 0/6] powerpc/rtas: miscellaneous cleanups, user region allocation Nathan Lynch
2021-01-14 21:59 ` [PATCH 1/6] powerpc/rtas: improve ppc_rtas_rmo_buf_show documentation Nathan Lynch
2021-01-15  4:38   ` Alexey Kardashevskiy
2021-01-15  5:50   ` Andrew Donnellan
2021-01-14 22:00 ` [PATCH 2/6] powerpc/rtas-proc: remove unused RMO_READ_BUF_MAX Nathan Lynch
2021-01-15  4:38   ` Alexey Kardashevskiy
2021-01-15  5:52   ` Andrew Donnellan
2021-01-14 22:00 ` [PATCH 3/6] powerpc/rtas: remove ibm_suspend_me_token Nathan Lynch
2021-01-15  4:38   ` Alexey Kardashevskiy
2021-01-15  5:52   ` Andrew Donnellan
2021-01-14 22:00 ` [PATCH 4/6] powerpc/rtas: move syscall filter setup into separate function Nathan Lynch
2021-01-15  4:39   ` Alexey Kardashevskiy
2021-01-15 16:04     ` Nathan Lynch
2021-01-15  5:49   ` Andrew Donnellan
2021-01-14 22:00 ` [PATCH 5/6] powerpc/rtas: rename RTAS_RMOBUF_MAX to RTAS_USER_REGION_SIZE Nathan Lynch
2021-01-15  4:38   ` Alexey Kardashevskiy
2021-01-15 15:56     ` Nathan Lynch
2021-01-18  4:15       ` Alexey Kardashevskiy
2021-01-20  1:17         ` Nathan Lynch
2021-01-20  5:05           ` Alexey Kardashevskiy
2021-01-21 15:17             ` Nathan Lynch
2021-01-15  6:10   ` Andrew Donnellan
2021-01-15 12:04   ` kernel test robot
2021-01-15 12:04     ` kernel test robot
2021-01-14 22:00 ` [PATCH 6/6] powerpc/rtas: constrain user region allocation to RMA Nathan Lynch
2021-01-15  4:38   ` Alexey Kardashevskiy
2021-01-15 15:38     ` Nathan Lynch
2021-01-18  4:12       ` Alexey Kardashevskiy
2021-01-20  0:39         ` Nathan Lynch
2021-01-20  4:49           ` Alexey Kardashevskiy
2021-01-20 12:06           ` Michael Ellerman
2021-01-21 15:27             ` Nathan Lynch
2021-01-23  1:54               ` Alexey Kardashevskiy
2021-01-19  9:00   ` Michael Ellerman
2021-01-19 21:00     ` Nathan Lynch [this message]
2021-01-20 12:13       ` Michael Ellerman
2021-01-21  0:26         ` Nathan Lynch

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=874kjcy73z.fsf@linux.ibm.com \
    --to=nathanl@linux.ibm.com \
    --cc=aik@ozlabs.ru \
    --cc=ajd@linux.ibm.com \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=brking@linux.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=tyreld@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.