xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@arm.com>
To: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Cc: "tee-dev@lists.linaro.org" <tee-dev@lists.linaro.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/5] xen/arm: optee: impose limit on shared buffer size
Date: Tue, 17 Sep 2019 11:49:13 +0100	[thread overview]
Message-ID: <907b2436-6b46-59d2-e2b3-39c593e7af12@arm.com> (raw)
In-Reply-To: <87d0g0feir.fsf@epam.com>

Hi Volodymyr,

On 9/16/19 4:26 PM, Volodymyr Babchuk wrote:
> 
> Hi Julien,
> 
> Julien Grall writes:
> 
>> Hi,
>>
>> 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"?
>>>>> Yes
>>>>>
>>>>>> If so, why 512 pages (i.e 1MB)
> I have missed that earlier. But 512 pages is 2MB, actually.
> 
>>>>>> is plenty enough for most of the use cases? What does "xtest" consist
>>>>>> on?
>>>>> 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?
> GP Spec says, that platform should allow *at lest* 512KB. Upper limit is
> not set.
> 
>> 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.
> I have no strong arguments here, but I want to allow the biggest size
> possible. It seems, that 512 pages is the accepted limit in hypervisor
> code (at least, in p2m.c), so I chose this value.

If GP specific request at least 512KB, then any portable code should be 
able to deal with 512KB, right? So why would you allow more? What are 
the cons/pros?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-09-17 10:50 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-23 18:48 [Xen-devel] [PATCH 0/5] arch/arm: optee: fix TODOs and remove "experimental" status Volodymyr Babchuk
2019-08-23 18:48 ` [Xen-devel] [PATCH 1/5] xen/arm: optee: impose limit on shared buffer size Volodymyr Babchuk
2019-09-09 22:11   ` Julien Grall
2019-09-11 18:48     ` Volodymyr Babchuk
2019-09-12 19:32       ` Julien Grall
2019-09-12 19:45         ` Volodymyr Babchuk
2019-09-12 19:51           ` Julien Grall
2019-09-16 15:26             ` Volodymyr Babchuk
2019-09-17 10:49               ` Julien Grall [this message]
2019-09-17 12:28                 ` Volodymyr Babchuk
2019-09-17 18:46                   ` Julien Grall
2019-08-23 18:48 ` [Xen-devel] [PATCH 2/5] xen/arm: optee: check for preemption while freeing shared buffers Volodymyr Babchuk
2019-09-09 22:19   ` Julien Grall
2019-09-11 18:53     ` Volodymyr Babchuk
2019-09-12 19:39       ` Julien Grall
2019-09-12 19:47         ` Volodymyr Babchuk
2019-08-23 18:48 ` [Xen-devel] [PATCH 3/5] xen/arm: optee: limit number of " Volodymyr Babchuk
2019-08-23 18:48 ` [Xen-devel] [PATCH 4/5] xen/arm: optee: handle share buffer translation error Volodymyr Babchuk
2019-09-10 11:17   ` Julien Grall
2019-09-11 18:32     ` Volodymyr Babchuk
2019-09-12 18:55       ` Julien Grall
2019-08-23 18:48 ` [Xen-devel] [PATCH 5/5] xen/arm: optee: remove experimental status Volodymyr Babchuk
2019-08-23 19:05   ` Julien Grall
2019-08-23 19:20     ` Volodymyr Babchuk
2019-09-09 21:31       ` Julien Grall
2019-09-11 18:41         ` Volodymyr Babchuk
2019-09-12 19:00           ` Julien Grall

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=907b2436-6b46-59d2-e2b3-39c593e7af12@arm.com \
    --to=julien.grall@arm.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=sstabellini@kernel.org \
    --cc=tee-dev@lists.linaro.org \
    --cc=xen-devel@lists.xenproject.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).