lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Tue, 08 Sep 2009 11:58:35 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Miroslav Rezanina <mrezanin@...hat.com>
CC:	linux-kernel@...r.kernel.org, xen-devel@...ts.xensource.com,
	Gianluca Guida <gianluca.guida@...rix.com>
Subject: Re: [PATCH][v2.6.29][XEN] Return unused memory to hypervisor

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ