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,