[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/5] xen/arm: optee: impose limit on shared buffer size


On 9/12/19 8:45 PM, Volodymyr Babchuk wrote:

Hi Julien,

Julien Grall writes:

Hi Volodymyr,

On 9/11/19 7:48 PM, Volodymyr Babchuk wrote:

Julien Grall writes:

Hi Volodymyr,

On 8/23/19 7:48 PM, Volodymyr Babchuk wrote:
We want to limit number of calls to lookup_and_pin_guest_ram_addr()
per one request. There are two ways to do this: either preempt
translate_noncontig() or to limit size of one shared buffer size.

It is quite hard to preempt translate_noncontig(), because it is deep
nested. So we chose second option. We will allow 512 pages per one
shared buffer. This does not interfere with GP standard, as it
requires that size limit for shared buffer should be at lest 512kB.

Do you mean "least" instead of "lest"?

If so, why 512 pages (i.e 1MB)
is plenty enough for most of the use cases? What does "xtest" consist
Bigger buffer xtest tries to allocate is mere 32KB. I believe that 1MB
is enough for the most cases, because OP-TEE itself have a very limited
resources. But this value is chosen arbitrary.

Could we potentially reduce to let say 512KB (or maybe lower) if xtest
only allocate 32KB?
Potentially - yes. But only to 512KB if we want to be compatible with
the Global Platform specification. Why are you asking, though?

Does the Global Platform specification limit to 512KB? Or is it a minimum?

Because, the smaller the buffer is, the less time it will take to process in the worst case. Also, if we can have a reason for the size (you seem to suggest the spec define a size...) then it is much better than a random value.


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.