Re: kexec-ed kernel possibly needing low memory

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Fri, Nov 14, 2014 at 11:02:54AM +0000, David Vrabel wrote:
> On 14/11/14 10:00, Jan Beulich wrote:
> > David,
> > 
> > we're being approached with the situation where a disk driver in the
> > kexec-ed kernel needs memory below 4G in order to perform DMA
> > (e.g. for the swiotlb to be set up). Linux not so long ago invented a
> > two area approach, which doesn't fit with the current single
> > KEXEC_RANGE_MA_CRASH area obtainable via
> > KEXEC_CMD_kexec_get_range.
> > 
> > I see multiple options
> > - do no change at all; the user can deal with this by explicitly
> >   specifying an area below 4G via "crashkernel="
> 
> This is what we do.
> 
> > - add KEXEC_RANGE_MA_CRASH_LOW
> 
> If you choose this option, it would be preferable to support N (which
> might be 2) arbitrary crash regions rather than specifying that one
> region is always low memory.  I would suggest combining this with a way
> to specify the bounds of each region.
> 
> e.g., crashkernel=32M@<4G,128M

We could also implement the 'autoplacement' feature that Red Hat has put
in their kexec implementation (not sure if it was upstreamed).

That would nicely deal with this by always putting it under 4GB.
> 
> I wouldn't go this route unless you actually need a large crash region
> that would use up too much low memory otherwise.
> 
> > - when not asked for a specific address, always allocate the (single)
> >   area below 4G if there is enough space
> 
> I don't think the default location should change.  A user might have
> specified  a large crash region that might use up most of low memory.
> 
> > - provide a means to request allocating the (single) area below 4G
> >   (or perhaps more generically below a certain boundary) without
> >   requiring an exact address to be specified
> 
> This sounds ok.
> 
> > Do you have any preference here, or do you see other viable
> > alternatives?
> 
> My preference would be option 1 since it already works, then option 4.
> 
> David
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel