From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>,
xen-devel <xen-devel@lists.xenproject.org>
Cc: Keir Fraser <keir@xen.org>
Subject: Re: [PATCH] x86/Dom0: account for shadow/HAP allocation
Date: Wed, 25 Feb 2015 17:06:09 +0000 [thread overview]
Message-ID: <54EE0101.4000804@citrix.com> (raw)
In-Reply-To: <54EDEE080200007800063AA4@mail.emea.novell.com>
On 25/02/15 14:45, Jan Beulich wrote:
> ... when calculating how many pages to allocate fopr Dom0. This is
"fopr" => "for" ?
> basically equivalent to the already present IOMMU related adjustment.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/arch/x86/domain_build.c
> +++ b/xen/arch/x86/domain_build.c
> @@ -132,6 +132,8 @@ struct vcpu *__init alloc_dom0_vcpu0(str
> #ifdef CONFIG_SHADOW_PAGING
> static bool_t __initdata opt_dom0_shadow;
> boolean_param("dom0_shadow", opt_dom0_shadow);
> +#else
> +#define opt_dom0_shadow 0
> #endif
>
> static char __initdata opt_dom0_ioports_disable[200] = "";
> @@ -203,13 +205,23 @@ static struct page_info * __init alloc_c
> return page;
> }
>
> +static unsigned long __init dom0_paging_pages(const struct domain *d,
> + unsigned long nr_pages)
> +{
> + /* Copied from: libxl_get_required_shadow_memory() */
> + unsigned long memkb = nr_pages * (PAGE_SIZE / 1024);
> +
> + memkb = 4 * (256 * d->max_vcpus + 2 * (memkb / 1024));
I have recently raised a bug against Xapi for similar wrong logic when
calculating the size of the shadow pool.
A per-vcpu reservation of shadow allocation is only needed if shadow
paging is actually in use, and even then should match
shadow_min_acceptable_pages() at 128 pages per vcpu.
If HAP is in use, the only allocations from the shadow pool are for the
EPT/NPT tables (1% of nr_pages), IOMMU tables (another 1% of nr_pages if
in use), and the logdirty radix tree (substantially less than than 1% of
nr_pages).
One could argue that structure such as the vmcs/vmcb should have their
allocations accounted against the domain, in which case a small per-vcpu
component would be appropriate.
However as it currently stands, this calculation wastes 4MB of ram per
vcpu in shadow allocation which is not going to be used.
~Andrew
> +
> + return ((memkb + 1023) / 1024) << (20 - PAGE_SHIFT);
> +}
> +
> static unsigned long __init compute_dom0_nr_pages(
> struct domain *d, struct elf_dom_parms *parms, unsigned long initrd_len)
> {
> unsigned long avail = avail_domheap_pages() + initial_images_nrpages();
> - unsigned long nr_pages = dom0_nrpages;
> - unsigned long min_pages = dom0_min_nrpages;
> - unsigned long max_pages = dom0_max_nrpages;
> + unsigned long nr_pages, min_pages, max_pages;
> + bool_t need_paging;
>
> /* Reserve memory for further dom0 vcpu-struct allocations... */
> avail -= (d->max_vcpus - 1UL)
> @@ -227,23 +239,37 @@ static unsigned long __init compute_dom0
> avail -= max_pdx >> s;
> }
>
> - /*
> - * If domain 0 allocation isn't specified, reserve 1/16th of available
> - * memory for things like DMA buffers. This reservation is clamped to
> - * a maximum of 128MB.
> - */
> - if ( nr_pages == 0 )
> - nr_pages = -min(avail / 16, 128UL << (20 - PAGE_SHIFT));
> + need_paging = opt_dom0_shadow || (is_pvh_domain(d) && !iommu_hap_pt_share);
> + for ( ; ; need_paging = 0 )
> + {
> + nr_pages = dom0_nrpages;
> + min_pages = dom0_min_nrpages;
> + max_pages = dom0_max_nrpages;
> +
> + /*
> + * If allocation isn't specified, reserve 1/16th of available memory
> + * for things like DMA buffers. This reservation is clamped to a
> + * maximum of 128MB.
> + */
> + if ( nr_pages == 0 )
> + nr_pages = -min(avail / 16, 128UL << (20 - PAGE_SHIFT));
>
> - /* Negative memory specification means "all memory - specified amount". */
> - if ( (long)nr_pages < 0 ) nr_pages += avail;
> - if ( (long)min_pages < 0 ) min_pages += avail;
> - if ( (long)max_pages < 0 ) max_pages += avail;
> -
> - /* Clamp dom0 memory according to min/max limits and available memory. */
> - nr_pages = max(nr_pages, min_pages);
> - nr_pages = min(nr_pages, max_pages);
> - nr_pages = min(nr_pages, avail);
> + /* Negative specification means "all memory - specified amount". */
> + if ( (long)nr_pages < 0 ) nr_pages += avail;
> + if ( (long)min_pages < 0 ) min_pages += avail;
> + if ( (long)max_pages < 0 ) max_pages += avail;
> +
> + /* Clamp according to min/max limits and available memory. */
> + nr_pages = max(nr_pages, min_pages);
> + nr_pages = min(nr_pages, max_pages);
> + nr_pages = min(nr_pages, avail);
> +
> + if ( !need_paging )
> + break;
> +
> + /* Reserve memory for shadow or HAP. */
> + avail -= dom0_paging_pages(d, nr_pages);
> + }
>
> if ( (parms->p2m_base == UNSET_ADDR) && (dom0_nrpages <= 0) &&
> ((dom0_min_nrpages <= 0) || (nr_pages > min_pages)) )
> @@ -1287,14 +1313,7 @@ int __init construct_dom0(
> }
>
> if ( is_pvh_domain(d) )
> - {
> - unsigned long hap_pages, memkb = nr_pages * (PAGE_SIZE / 1024);
> -
> - /* Copied from: libxl_get_required_shadow_memory() */
> - memkb = 4 * (256 * d->max_vcpus + 2 * (memkb / 1024));
> - hap_pages = ( (memkb + 1023) / 1024) << (20 - PAGE_SHIFT);
> - hap_set_alloc_for_pvh_dom0(d, hap_pages);
> - }
> + hap_set_alloc_for_pvh_dom0(d, dom0_paging_pages(d, nr_pages));
>
> /*
> * We enable paging mode again so guest_physmap_add_page will do the
>
>
next prev parent reply other threads:[~2015-02-25 17:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-25 14:45 [PATCH] x86/Dom0: account for shadow/HAP allocation Jan Beulich
2015-02-25 17:06 ` Andrew Cooper [this message]
2015-02-26 7:43 ` Jan Beulich
2015-02-27 12:02 ` Andrew Cooper
2015-02-27 13:21 ` Jan Beulich
2015-02-27 14:45 ` Andrew Cooper
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=54EE0101.4000804@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=keir@xen.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.