Re: [Xen-devel] [PATCH v8 13/15] xen: make grant resource limits per domain

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.09.17 at 09:53, <jgross@xxxxxxxx> wrote:
> On 21/09/17 08:15, Jan Beulich wrote:
>>>>> On 21.09.17 at 06:35, <jgross@xxxxxxxx> wrote:
>>> On 20/09/17 17:35, Jan Beulich wrote:
>>>>>>> On 20.09.17 at 14:44, <jgross@xxxxxxxx> wrote:
>>>>> On 20/09/17 13:48, Jan Beulich wrote:
>>>>>>>>> On 20.09.17 at 13:10, <jgross@xxxxxxxx> wrote:
>>>>>>> I thought about a cap and TBH I'm not sure which would be sane to
>>>>>>> apply. The global limits seem wrong, especially looking at patch 14:
>>>>>>> those limits will be for dom0 only then. And dom0 won't need many
>>>>>>> grant frames in the normal case...
>>>>>>
>>>>>> I've been thinking about this Dom0 aspect too over lunch. What
>>>>>> about allowing the hardware domain to set its limit (only upwards
>>>>>> of course) in setup_table(), without any upper bound enforced?
>>>>>> This would free up the globals to be used as system wide limits
>>>>>> again.
>>>>>
>>>>> This would be possible, of course.
>>>>>
>>>>> The question is whether the need to re-allocate the frame pointer arrays
>>>>> is it worth.
>>>>
>>>> Input by others would be helpful...
>>>
>>> I think I'll go with additional cap boot parameters, so I don't think
>>> we need dom0 to modify its own limits.
>> 
>> So are we in agreement then that no new command line options
>> are needed, and that hence the cap will be applicable to all
>> domains (with Dom0 simply not having any other limit enforced
>> on it)?
> 
> Hmm, I meant this to be the other way round: having distinct parameters
> for dom0 and the cap.
> 
> In case you like it much better to merge them I won't argue over it.

Well, late yesterday evening it occurred to me that it would
only be consistent to apply the same cap to all domains. That's
in particular to not penalize a non-Dom0 hardware domain in
comparison with Dom0 itself.

> In this case annotating the variables with __init would be moot, of
> course.

Of course.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel