From: Juergen Gross <jgross@suse.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: sstabellini@kernel.org, wei.liu2@citrix.com,
George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
ian.jackson@eu.citrix.com, tim@xen.org, julien.grall@arm.com,
xen-devel@lists.xenproject.org, dgdegra@tycho.nsa.gov
Subject: Re: [PATCH v8 13/15] xen: make grant resource limits per domain
Date: Thu, 21 Sep 2017 13:39:15 +0200 [thread overview]
Message-ID: <f95b7d5b-2cb7-109d-f4a7-ebfc0e947315@suse.com> (raw)
In-Reply-To: <59C3BF28020000780017DE68@suse.com>
On 21/09/17 13:31, Jan Beulich wrote:
>>>> On 21.09.17 at 09:53, <jgross@suse.com> wrote:
>> On 21/09/17 08:15, Jan Beulich wrote:
>>>>>> On 21.09.17 at 06:35, <jgross@suse.com> wrote:
>>>> On 20/09/17 17:35, Jan Beulich wrote:
>>>>>>>> On 20.09.17 at 14:44, <jgross@suse.com> wrote:
>>>>>> On 20/09/17 13:48, Jan Beulich wrote:
>>>>>>>>>> On 20.09.17 at 13:10, <jgross@suse.com> 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.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-09-21 11:39 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-20 6:34 [PATCH v8 00/15] xen: better grant v2 support Juergen Gross
2017-09-20 6:34 ` [PATCH v8 01/15] xen: move XENMAPSPACE_grant_table code into grant_table.c Juergen Gross
2017-09-20 12:40 ` Julien Grall
2017-09-20 6:34 ` [PATCH v8 02/15] xen: clean up grant_table.h Juergen Gross
2017-09-20 6:34 ` [PATCH v8 03/15] xen: add new domctl hypercall to set grant table resource limits Juergen Gross
2017-09-20 8:26 ` Paul Durrant
2017-09-20 8:49 ` Jan Beulich
2017-09-20 6:34 ` [PATCH v8 04/15] xen: add function for obtaining highest possible memory address Juergen Gross
2017-09-20 8:57 ` Jan Beulich
[not found] ` <59C2499A020000780017D412@suse.com>
2017-09-20 8:58 ` Juergen Gross
2017-09-20 9:32 ` Jan Beulich
[not found] ` <59C251C8020000780017D4D7@suse.com>
2017-09-20 9:39 ` Juergen Gross
2017-09-20 12:51 ` Julien Grall
2017-09-20 13:08 ` Juergen Gross
2017-09-20 14:24 ` Julien Grall
2017-09-20 14:33 ` Juergen Gross
2017-09-20 17:15 ` Julien Grall
2017-09-21 4:18 ` Juergen Gross
2017-09-20 6:34 ` [PATCH v8 05/15] xen: add max possible mfn to struct xen_sysctl_physinfo Juergen Gross
2017-09-20 8:58 ` Jan Beulich
[not found] ` <59C249F3020000780017D415@suse.com>
2017-09-20 9:00 ` Juergen Gross
2017-09-20 12:53 ` Julien Grall
2017-09-20 13:06 ` Juergen Gross
2017-09-20 6:34 ` [PATCH v8 06/15] libxc: add libxc support for setting grant table resource limits Juergen Gross
2017-09-20 6:34 ` [PATCH v8 07/15] tools: set grant limits for xenstore stubdom Juergen Gross
2017-09-20 6:34 ` [PATCH v8 08/15] libxl: add max possible mfn to libxl_physinfo Juergen Gross
2017-09-20 6:34 ` [PATCH v8 09/15] xl: add global grant limit config items Juergen Gross
2017-09-20 6:34 ` [PATCH v8 10/15] libxl: add libxl support for setting grant table resource limits Juergen Gross
2017-09-20 6:34 ` [PATCH v8 11/15] xen: delay allocation of grant table sub structures Juergen Gross
2017-09-20 9:22 ` Jan Beulich
[not found] ` <59C24F80020000780017D473@suse.com>
2017-09-20 9:44 ` Juergen Gross
2017-09-20 10:02 ` Jan Beulich
[not found] ` <59C258D4020000780017D521@suse.com>
2017-09-20 10:05 ` Juergen Gross
2017-09-20 6:34 ` [PATCH v8 12/15] xen/arm: move arch specific grant table bits into grant_table.c Juergen Gross
2017-09-20 9:25 ` Jan Beulich
2017-09-20 14:34 ` Julien Grall
2017-09-21 4:36 ` Juergen Gross
2017-09-20 6:34 ` [PATCH v8 13/15] xen: make grant resource limits per domain Juergen Gross
2017-09-20 10:34 ` Jan Beulich
2017-09-20 14:37 ` Julien Grall
[not found] ` <59C2603C020000780017D561@suse.com>
2017-09-20 11:10 ` Juergen Gross
2017-09-20 11:48 ` Jan Beulich
[not found] ` <59C271B9020000780017D620@suse.com>
2017-09-20 12:44 ` Juergen Gross
2017-09-20 15:35 ` Jan Beulich
[not found] ` <59C2A6DE020000780017D874@suse.com>
2017-09-21 4:35 ` Juergen Gross
2017-09-21 6:15 ` Jan Beulich
[not found] ` <59C3751D020000780017DCB6@suse.com>
2017-09-21 7:53 ` Juergen Gross
2017-09-21 11:31 ` Jan Beulich
[not found] ` <59C3BF28020000780017DE68@suse.com>
2017-09-21 11:39 ` Juergen Gross [this message]
2017-09-21 11:48 ` Jan Beulich
[not found] ` <59C3C33E020000780017DEC3@suse.com>
2017-09-21 11:51 ` Juergen Gross
2017-09-22 6:19 ` Juergen Gross
2017-09-22 7:53 ` Jan Beulich
[not found] ` <59C4DD9B020000780017E575@suse.com>
2017-09-22 8:27 ` Juergen Gross
2017-09-22 8:35 ` Jan Beulich
[not found] ` <59C4E78B020000780017E67D@suse.com>
2017-09-22 8:44 ` Juergen Gross
2017-09-22 8:51 ` Jan Beulich
2017-09-20 6:34 ` [PATCH v8 14/15] xen: make grant table limits boot parameters dom0 only Juergen Gross
2017-09-20 12:07 ` Jan Beulich
[not found] ` <59C27619020000780017D66F@suse.com>
2017-09-20 12:48 ` Juergen Gross
2017-09-20 15:36 ` Jan Beulich
[not found] ` <59C2A72D020000780017D881@suse.com>
2017-09-21 4:27 ` Juergen Gross
2017-09-21 6:16 ` Jan Beulich
2017-09-20 6:34 ` [PATCH v8 15/15] xen: add new Xen cpuid node for max address width info Juergen Gross
2017-09-20 12:18 ` Jan Beulich
[not found] ` <59C278A3020000780017D689@suse.com>
2017-09-20 12:58 ` Juergen Gross
2017-09-20 15:42 ` Jan Beulich
[not found] ` <59C2A880020000780017D8A2@suse.com>
2017-09-21 4:21 ` Juergen Gross
2017-09-20 13:00 ` Julien Grall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f95b7d5b-2cb7-109d-f4a7-ebfc0e947315@suse.com \
--to=jgross@suse.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=dgdegra@tycho.nsa.gov \
--cc=ian.jackson@eu.citrix.com \
--cc=julien.grall@arm.com \
--cc=sstabellini@kernel.org \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).