From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
Jeremy.Fitzhardinge@citrix.com,
Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [PATCH v3 08/10] xen: use host E820 map for dom0
Date: Mon, 18 Oct 2010 11:54:12 -0400 [thread overview]
Message-ID: <20101018155412.GD27373@dumpdata.com> (raw)
In-Reply-To: <1286901770-8612-8-git-send-email-Stefano.Stabellini@eu.citrix.com>
On Tue, Oct 12, 2010 at 05:42:48PM +0100, Stefano Stabellini wrote:
> From: Ian Campbell <ian.campbell@citrix.com>
>
> When running as initial domain, get the real physical memory map from
> xen using the XENMEM_machine_memory_map hypercall and use it to setup
> the e820 regions.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
> arch/x86/xen/setup.c | 43 +++++++++++++++++++++++++++++++++++++--
> include/xen/interface/memory.h | 28 ++++++++++++++++++++++++++
> 2 files changed, 68 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 62ceb78..b08aac2 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -107,14 +107,51 @@ static unsigned long __init xen_return_unused_memory(unsigned long max_pfn,
>
> char * __init xen_memory_setup(void)
> {
> + static __initdata struct e820entry map[E820MAX];
> +
> unsigned long max_pfn = xen_start_info->nr_pages;
> + struct xen_memory_map memmap;
> + unsigned long long mem_end;
> + int op;
> + int rc;
> + int i;
>
> max_pfn = min(MAX_DOMAIN_PAGES, max_pfn);
> + mem_end = PFN_PHYS((u64)max_pfn);
> +
> + memmap.nr_entries = E820MAX;
> + set_xen_guest_handle(memmap.buffer, map);
> +
> + op = xen_initial_domain() ?
> + XENMEM_machine_memory_map :
> + XENMEM_memory_map;
> + rc = HYPERVISOR_memory_op(op, &memmap);
> + if (rc == -ENOSYS) {
> + memmap.nr_entries = 1;
> + map[0].addr = 0ULL;
> + map[0].size = mem_end;
> + /* 8MB slack (to balance backend allocations). */
> + map[0].size += 8ULL << 20;
> + map[0].type = E820_RAM;
> + rc = 0;
> + }
> + BUG_ON(rc);
>
> e820.nr_map = 0;
> -
> - e820_add_region(0, PFN_PHYS((u64)max_pfn), E820_RAM);
> -
> + for (i = 0; i < memmap.nr_entries; i++) {
> + unsigned long long end = map[i].addr + map[i].size;
> + if (map[i].type == E820_RAM) {
> + if (map[i].addr > mem_end)
> + continue;
Would it make sense to print out a message saying something to the
effect of: "You need to increase the CONFIG_XEN_MAX_DOMAIN_MEMORY value to
take advantage of the extra %d gobs of memory!\n", map[i].size
Or will this be unneccessary with the later changes that Jeremy has
for the balloon work?
> + if (end > mem_end) {
> + /* Truncate region to max_mem. */
> + map[i].size -= end - mem_end;
> + }
> + }
> + if (map[i].size > 0)
> + e820_add_region(map[i].addr, map[i].size, map[i].type);
> + }
> +
> /*
> * Even though this is normal, usable memory under Xen, reserve
> * ISA memory anyway because too many things think they can poke
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index d3938d3..4c4b817 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -186,6 +186,34 @@ struct xen_translate_gpfn_list {
> };
> DEFINE_GUEST_HANDLE_STRUCT(xen_translate_gpfn_list);
>
> +/*
> + * Returns the pseudo-physical memory map as it was when the domain
> + * was started (specified by XENMEM_set_memory_map).
> + * arg == addr of struct xen_memory_map.
> + */
> +#define XENMEM_memory_map 9
> +struct xen_memory_map {
> + /*
> + * On call the number of entries which can be stored in buffer. On
> + * return the number of entries which have been stored in
> + * buffer.
> + */
> + unsigned int nr_entries;
> +
> + /*
> + * Entries in the buffer are in the same format as returned by the
> + * BIOS INT 0x15 EAX=0xE820 call.
> + */
> + GUEST_HANDLE(void) buffer;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map);
> +
> +/*
> + * Returns the real physical memory map. Passes the same structure as
> + * XENMEM_memory_map.
> + * arg == addr of struct xen_memory_map.
> + */
> +#define XENMEM_machine_memory_map 10
>
> /*
> * Prevent the balloon driver from changing the memory reservation
> --
> 1.5.6.5
WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Cc: Jeremy.Fitzhardinge@citrix.com, xen-devel@lists.xensource.com,
linux-kernel@vger.kernel.org,
Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [PATCH v3 08/10] xen: use host E820 map for dom0
Date: Mon, 18 Oct 2010 11:54:12 -0400 [thread overview]
Message-ID: <20101018155412.GD27373@dumpdata.com> (raw)
In-Reply-To: <1286901770-8612-8-git-send-email-Stefano.Stabellini@eu.citrix.com>
On Tue, Oct 12, 2010 at 05:42:48PM +0100, Stefano Stabellini wrote:
> From: Ian Campbell <ian.campbell@citrix.com>
>
> When running as initial domain, get the real physical memory map from
> xen using the XENMEM_machine_memory_map hypercall and use it to setup
> the e820 regions.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
> arch/x86/xen/setup.c | 43 +++++++++++++++++++++++++++++++++++++--
> include/xen/interface/memory.h | 28 ++++++++++++++++++++++++++
> 2 files changed, 68 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 62ceb78..b08aac2 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -107,14 +107,51 @@ static unsigned long __init xen_return_unused_memory(unsigned long max_pfn,
>
> char * __init xen_memory_setup(void)
> {
> + static __initdata struct e820entry map[E820MAX];
> +
> unsigned long max_pfn = xen_start_info->nr_pages;
> + struct xen_memory_map memmap;
> + unsigned long long mem_end;
> + int op;
> + int rc;
> + int i;
>
> max_pfn = min(MAX_DOMAIN_PAGES, max_pfn);
> + mem_end = PFN_PHYS((u64)max_pfn);
> +
> + memmap.nr_entries = E820MAX;
> + set_xen_guest_handle(memmap.buffer, map);
> +
> + op = xen_initial_domain() ?
> + XENMEM_machine_memory_map :
> + XENMEM_memory_map;
> + rc = HYPERVISOR_memory_op(op, &memmap);
> + if (rc == -ENOSYS) {
> + memmap.nr_entries = 1;
> + map[0].addr = 0ULL;
> + map[0].size = mem_end;
> + /* 8MB slack (to balance backend allocations). */
> + map[0].size += 8ULL << 20;
> + map[0].type = E820_RAM;
> + rc = 0;
> + }
> + BUG_ON(rc);
>
> e820.nr_map = 0;
> -
> - e820_add_region(0, PFN_PHYS((u64)max_pfn), E820_RAM);
> -
> + for (i = 0; i < memmap.nr_entries; i++) {
> + unsigned long long end = map[i].addr + map[i].size;
> + if (map[i].type == E820_RAM) {
> + if (map[i].addr > mem_end)
> + continue;
Would it make sense to print out a message saying something to the
effect of: "You need to increase the CONFIG_XEN_MAX_DOMAIN_MEMORY value to
take advantage of the extra %d gobs of memory!\n", map[i].size
Or will this be unneccessary with the later changes that Jeremy has
for the balloon work?
> + if (end > mem_end) {
> + /* Truncate region to max_mem. */
> + map[i].size -= end - mem_end;
> + }
> + }
> + if (map[i].size > 0)
> + e820_add_region(map[i].addr, map[i].size, map[i].type);
> + }
> +
> /*
> * Even though this is normal, usable memory under Xen, reserve
> * ISA memory anyway because too many things think they can poke
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index d3938d3..4c4b817 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -186,6 +186,34 @@ struct xen_translate_gpfn_list {
> };
> DEFINE_GUEST_HANDLE_STRUCT(xen_translate_gpfn_list);
>
> +/*
> + * Returns the pseudo-physical memory map as it was when the domain
> + * was started (specified by XENMEM_set_memory_map).
> + * arg == addr of struct xen_memory_map.
> + */
> +#define XENMEM_memory_map 9
> +struct xen_memory_map {
> + /*
> + * On call the number of entries which can be stored in buffer. On
> + * return the number of entries which have been stored in
> + * buffer.
> + */
> + unsigned int nr_entries;
> +
> + /*
> + * Entries in the buffer are in the same format as returned by the
> + * BIOS INT 0x15 EAX=0xE820 call.
> + */
> + GUEST_HANDLE(void) buffer;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map);
> +
> +/*
> + * Returns the real physical memory map. Passes the same structure as
> + * XENMEM_memory_map.
> + * arg == addr of struct xen_memory_map.
> + */
> +#define XENMEM_machine_memory_map 10
>
> /*
> * Prevent the balloon driver from changing the memory reservation
> --
> 1.5.6.5
next prev parent reply other threads:[~2010-10-18 15:54 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-12 16:41 [PATCH v3 00/10] xen: initial domain support Stefano Stabellini
2010-10-12 16:42 ` [PATCH v3 01/10] xen: introduce XEN_DOM0 as a silent option Stefano Stabellini
2010-10-12 16:42 ` [PATCH v3 02/10] xen: remap GSIs as pirqs when running as initial domain Stefano Stabellini
2010-10-18 15:41 ` Konrad Rzeszutek Wilk
2010-10-18 15:41 ` Konrad Rzeszutek Wilk
2010-10-19 10:41 ` Stefano Stabellini
2010-10-19 10:41 ` Stefano Stabellini
2010-10-19 15:48 ` [Xen-devel] " Konrad Rzeszutek Wilk
2010-10-19 15:48 ` Konrad Rzeszutek Wilk
2010-10-12 16:42 ` [PATCH v3 03/10] xen: remap MSIs into " Stefano Stabellini
2010-10-18 15:46 ` Konrad Rzeszutek Wilk
2010-10-18 15:46 ` Konrad Rzeszutek Wilk
2010-10-19 10:43 ` Stefano Stabellini
2010-10-19 10:43 ` Stefano Stabellini
2010-10-12 16:42 ` [PATCH v3 04/10] xen: map a dummy page for local apic and ioapic in xen_set_fixmap Stefano Stabellini
2010-10-12 16:42 ` [PATCH v3 05/10] xen: use vcpu_ops to setup cpu masks Stefano Stabellini
2010-10-12 16:42 ` [PATCH v3 06/10] xen: Initialize xenbus for dom0 Stefano Stabellini
2010-10-12 16:42 ` [PATCH v3 07/10] xen: add the direct mapping area for ISA bus access Stefano Stabellini
2010-10-12 16:42 ` [PATCH v3 08/10] xen: use host E820 map for dom0 Stefano Stabellini
2010-10-18 15:54 ` Konrad Rzeszutek Wilk [this message]
2010-10-18 15:54 ` Konrad Rzeszutek Wilk
2010-10-19 10:49 ` Stefano Stabellini
2010-10-19 10:49 ` Stefano Stabellini
2010-10-20 17:05 ` [Xen-devel] " Jeremy Fitzhardinge
2010-10-12 16:42 ` [PATCH v3 09/10] xen: make hvc_xen console work " Stefano Stabellini
2010-10-12 16:42 ` [PATCH v3 10/10] xen: mask the MTRR feature from the cpuid Stefano Stabellini
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=20101018155412.GD27373@dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=Jeremy.Fitzhardinge@citrix.com \
--cc=Stefano.Stabellini@eu.citrix.com \
--cc=ian.campbell@citrix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=xen-devel@lists.xensource.com \
/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.