From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Miroslav Rezanina <mrezanin@redhat.com>
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
Gianluca Guida <gianluca.guida@citrix.com>
Subject: Re: [PATCH][v2.6.29][XEN] Return unused memory to hypervisor
Date: Tue, 08 Sep 2009 11:58:35 -0700 [thread overview]
Message-ID: <4AA6A95B.2030602@goop.org> (raw)
In-Reply-To: <1864241231.701071252327314933.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
On 09/07/09 05:41, Miroslav Rezanina wrote:
> can you give me a practical example, where e820 map can have "hole" inside,
> i.e. there will be block of memory not listed in e820 map that have listed
> memory before and after it?
> As I checked the source code, there is always removed memory from some point
> till end of map, not from one adress till another. And I can't image how would
> be such a case handled. Of course, there can be some special regions, as the PCI
> hole, but these are marked as "Reserved".
> There can be "reserved and returned" some inside memory, but this is already
> handled by balloon driver. My patch returns memory that this driver can't use.
>
PCI memory isn't typically reserved; there's just a hole in the address
space for it. Its up to the BIOS/OS to set the BARs for the devices
into that hole. Reserved E820 regions are just that - reserved by the
BIOS for its own purposes.
In a Xen domain, the E820 tables are purely synthesized by the kernel's
Xen code, and can have any content we like. At the moment they tend to
be very simple with linear memory up to the domain's memory size. For
domains with PCI access - either dom0 or with pcifront - we want to be
able to carve out regions from that memory to place devices. We may
want to manipulate the E820 tables to reshape memory for other reasons
(like pre-ballooned memory, or memory hotplug).
What I'm looking for is a nice general purpose routine which will walk a
set of E820 entries and release back to Xen any memory which is in an
E820 hole (ie, in a gap between or after E820 entries). That solves the
simple problem of trimming the end of the memory map, but also copes
with more complex cases that will arise.
J
WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Miroslav Rezanina <mrezanin@redhat.com>
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
Gianluca Guida <gianluca.guida@citrix.com>
Subject: Re: [PATCH][v2.6.29][XEN] Return unused memory to hypervisor
Date: Tue, 08 Sep 2009 11:58:35 -0700 [thread overview]
Message-ID: <4AA6A95B.2030602@goop.org> (raw)
In-Reply-To: <1864241231.701071252327314933.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
On 09/07/09 05:41, Miroslav Rezanina wrote:
> can you give me a practical example, where e820 map can have "hole" inside,
> i.e. there will be block of memory not listed in e820 map that have listed
> memory before and after it?
> As I checked the source code, there is always removed memory from some point
> till end of map, not from one adress till another. And I can't image how would
> be such a case handled. Of course, there can be some special regions, as the PCI
> hole, but these are marked as "Reserved".
> There can be "reserved and returned" some inside memory, but this is already
> handled by balloon driver. My patch returns memory that this driver can't use.
>
PCI memory isn't typically reserved; there's just a hole in the address
space for it. Its up to the BIOS/OS to set the BARs for the devices
into that hole. Reserved E820 regions are just that - reserved by the
BIOS for its own purposes.
In a Xen domain, the E820 tables are purely synthesized by the kernel's
Xen code, and can have any content we like. At the moment they tend to
be very simple with linear memory up to the domain's memory size. For
domains with PCI access - either dom0 or with pcifront - we want to be
able to carve out regions from that memory to place devices. We may
want to manipulate the E820 tables to reshape memory for other reasons
(like pre-ballooned memory, or memory hotplug).
What I'm looking for is a nice general purpose routine which will walk a
set of E820 entries and release back to Xen any memory which is in an
E820 hole (ie, in a gap between or after E820 entries). That solves the
simple problem of trimming the end of the memory map, but also copes
with more complex cases that will arise.
J
next prev parent reply other threads:[~2009-09-08 18:58 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <131246341.771871250687008542.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
2009-08-19 13:05 ` [PATCH][v2.6.29][XEN] Return unused memory to hypervisor Miroslav Rezanina
2009-08-19 13:05 ` Miroslav Rezanina
2009-08-19 16:16 ` Jeremy Fitzhardinge
2009-08-20 7:47 ` Miroslav Rezanina
2009-08-20 7:47 ` Miroslav Rezanina
2009-08-20 16:39 ` Jeremy Fitzhardinge
2009-08-20 16:39 ` Jeremy Fitzhardinge
2009-09-07 12:41 ` Miroslav Rezanina
2009-09-07 12:41 ` Miroslav Rezanina
2009-09-08 18:58 ` Jeremy Fitzhardinge [this message]
2009-09-08 18:58 ` Jeremy Fitzhardinge
2009-08-20 9:31 ` [Xen-devel] " Gianluca Guida
2009-08-20 9:31 ` Gianluca Guida
2009-08-20 11:36 ` [PATCH v2][v2.6.29][XEN] " Miroslav Rezanina
2009-09-03 23:26 ` [PATCH][v2.6.29][XEN] " Jeremy Fitzhardinge
2009-09-03 23:26 ` Jeremy Fitzhardinge
2009-09-04 5:29 ` Miroslav Rezanina
[not found] <1152394510.61021250842386600.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
2009-08-21 8:14 ` Miroslav Rezanina
2009-08-21 8:14 ` Miroslav Rezanina
2009-08-21 11:51 ` Gianluca Guida
2009-08-21 11:51 ` Gianluca Guida
[not found] <1582654680.152201253087647836.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
2009-09-16 7:56 ` Miroslav Rezanina
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=4AA6A95B.2030602@goop.org \
--to=jeremy@goop.org \
--cc=gianluca.guida@citrix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mrezanin@redhat.com \
--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.