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

Re: [Xen-devel] [PATCH 2/5] xen/arm: optee: check for preemption while freeing shared buffers



Hi Volodymyr,

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

Julien Grall writes:

Hi Volodymyr,

On 8/23/19 7:48 PM, Volodymyr Babchuk wrote:
Now we have limit for one shared buffer size, so we can be sure that
one call to free_optee_shm_buf() will not free all
MAX_TOTAL_SMH_BUF_PG pages at once. Thus, we now can check for
hypercall_preempt_check() in the loop inside
optee_relinquish_resources() and this will ensure that we are not
missing preemption.

I am not sure to understand the correlation between the two
sentences. Even if previously the guest could pin up to
MAX_TOTAL_SHM_BUF_PG in one call, a well-behaved guest would result to
do multiple calls and therefore preemption would have been useful.
Looks like now I don't understand you.

I'm talking about shared buffers. We have limited shared buffer to some
reasonable size. There is bad- or well-behaving guests in this context,
because guest can't share one big buffer in multiple calls. In other
worlds, if guest *needs* to share 512MB buffer with OP-TEE, it will be
forced to do this in one call. But we are forbidding big buffers right
now.

optee_relinquish_resources() is called during domain destruction. At
this time we can have a number of still living shared buffers, each of
one is no bigger than 512 pages. Thanks to this, we can call
hypercall_preempt_check() only in optee_relinquish_resources(), but not
in free_optee_shm_buf().

I understand what you mean, however my point is that this patch does not dependent of the previous patch. Even if this patch goes alone, you will improve well-behaved guest. For ill-behaved guest, the problem will stay the same so no change.


If we will allow guest to register bigger buffer, than we will be forced
to check for preemption in free_optee_shm_buf() as well.

Well yes, however this patch would still be useful independently of the size of the buffer.

Cheers,

--
Julien Grall

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

 


Rackspace

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