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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.09.17 at 08:19, <jgross@xxxxxxxx> wrote:
> On 21/09/17 13:48, Jan Beulich wrote:
>>>>> On 21.09.17 at 13:39, <jgross@xxxxxxxx> wrote:
>>> On 21/09/17 13:31, Jan Beulich wrote:
>>>>>>> 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.
>>>
>>> That's correct.
>>>
>>> OTOH e.g. a cap of lets say 1024 grant frames but Dom0 configured to
>>> 4 only (why would it need more?) would make sense: the grant frame array
>>> for Dom0 would need 32 bytes only instead of the 8kB for the 1024 frames
>>> if the cap would be the configuration value for Dom0.
>> 
>> May I suggest that for now we use the simpler variant without
>> extra Dom0 command line options, and later (post 4.10), if you or
>> anyone else really feels like it, Dom0 specific options be introduced?
> 
> While applying these changes to my series I realized this might be a bad
> choice for ARM: the dom0 grant table is here limited to about 100 pages.
> If there is some need to have a domU with more grant frames the system
> wouldn't be able to boot as the high cap would be used for the dom0
> grant frame number.

Why can't ARM code lower the Dom0 values without lowering the
caps?

Jan


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