linux-kernel - Re: [PATCH R3 7/7] xen/balloon: Memory hotplug support for Xen balloon driver

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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 11 Feb 2011 15:22:18 -0800
From:	Dave Hansen <dave@...ux.vnet.ibm.com>
To:	Daniel Kiper <dkiper@...-space.pl>
Cc:	ian.campbell@...rix.com, akpm@...ux-foundation.org,
	andi.kleen@...el.com, haicheng.li@...ux.intel.com,
	fengguang.wu@...el.com, jeremy@...p.org, konrad.wilk@...cle.com,
	dan.magenheimer@...cle.com, v.tolstov@...fip.ru, pasik@....fi,
	wdauchy@...il.com, rientjes@...gle.com,
	xen-devel@...ts.xensource.com, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [PATCH R3 7/7] xen/balloon: Memory hotplug support for Xen
 balloon driver

On Sat, 2011-02-12 at 00:13 +0100, Daniel Kiper wrote:
> On Tue, Feb 08, 2011 at 09:22:26AM -0800, Dave Hansen wrote:
> > You spoke about page alignment up there.  Why is this section-aligned?
> > Should we make an "align to section" function in generic sparsemem code?
> 
> It is done because all pages in relevant section starting from max_pfn
> to the end of that section do not have PG_reserved bit set. It was tested
> on Linux Kernel Ver. 2.6.32.x, however, I am going to do some tests on
> current Linus tree. Currently, I do not expect that "align to section"
> function is required by others.

It doesn't matter if it gets used by anybody else.  It's a generic
function that fits in well with the other sparsemem code.  It should go
there.

...
> > As for telling the hypervisor where you've mapped things, that should be
> > done in arch_add_memory().
> >
> > When it comes down to online_page(), you don't want your pages freed
> > back in to the buddy allocator, you want them put in to the balloon.
> > So, take the __free_page() in online_page(), and put a Xen hook in
> > there.
> >
> > +void __attribute__((weak)) arch_free_hotplug_page(struct page *page)
> > +{
> > +	__free_page(page);
> > +}
> 
> I think that this function should be registered dynamically at init
> stage by specific balloon driver (in this case Xen balloon driver).

That sounds fine to me.  I guess we could use some of the subarch stuff
or the pv_ops structure to do it as well.  This isn't exactly a hot
path, either, so I'm not worried about it being some kind of
conditional.

Really, anything that allows us to divert pages over to the Xen balloon
driver rather than the buddy allocator is probably just fine.  

> > > Additionally, IIRC, add_memory() requires
> > > that underlying memory is available before its call.
> >
> > No, that's not correct.  s390's memory isn't available until after it
> > calls vmem_add_mapping().  See arch/s390/mm/init.c
> 
> I was right to some extent. First versions of memory hotplug code were
> written on the base of Linux Kernel Ver. 2.6.32.x. Tests done on that
> versions showed that add_memory() required that underlying memory should
> be available before its call. However, after short investigation it came
> out that there are some issues with some Xen calls. Those issues does
> not exists in current Linus tree.

Sounds good, I'm looking forward to your next patch.

-- Dave

--
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/