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

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



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.
In this case annotating the variables with __init would be moot, of
course.


Juergen


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

 


Rackspace

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