Re: Flask vs paging mempool - Was: [xen-unstable test] 174809: regressions - trouble: broken/fail/pass

[Jan Beulich <jbeulich@xxxxxxxx>]

On 20.11.2022 12:08, Daniel P. Smith wrote:
> On 11/18/22 16:10, Jason Andryuk wrote:
>> On Fri, Nov 18, 2022 at 12:22 PM Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx> 
>> wrote:
>>> For Flask, we need new access vectors because this is a common
>>> hypercall, but I'm unsure how to interlink it with x86's shadow
>>> control.  This will require a bit of pondering, but it is probably
>>> easier to just leave them unlinked.
>>
>> It sort of seems like it could go under domain2 since domain/domain2
>> have most of the memory stuff, but it is non-PV.  shadow has its own
>> set of hooks.  It could go in hvm which already has some memory stuff.
> 
> Since the new hypercall is for managing a memory pool for any domain, 
> though HVM is the only one supported today, imho it belongs under 
> domain/domain2.
> 
> Something to consider is that there is another guest memory pool that is 
> managed, the PoD pool, which has a dedicated privilege for it. This 
> leads me to the question of whether access to manage the PoD pool and 
> the paging pool size should be separate accesses or whether they should 
> be under the same access. IMHO I believe it should be the latter as I 
> can see no benefit in disaggregating access to the PoD pool and the 
> paging pool. In fact I find myself thinking in terms of should the 
> managing domain have control over the size of any backing memory pools 
> for the target domain. I am not seeing any benefit to discriminating 
> between which backing memory pool a managing domain should be able to 
> manage. With that said, I am open to being convinced otherwise.

Yet the two pools are of quite different nature: The PoD pool is memory
the domain itself gets to use (more precisely it is memory temporarily
"stolen" from the domain). The paging pool, otoh, is memory we need to
make the domain actually function, without the guest having access to
that memory.

Jan