[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 12/16 - RFC] x86/efi: create new early memory allocator



On Fri, May 27, 2016 at 02:37:06AM -0600, Jan Beulich wrote:
> >>> On 25.05.16 at 21:48, <daniel.kiper@xxxxxxxxxx> wrote:
> > On Wed, May 25, 2016 at 02:39:57AM -0600, Jan Beulich wrote:
> >> >>> On 15.04.16 at 14:33, <daniel.kiper@xxxxxxxxxx> wrote:

[...]

> >> > Jan Beulich added 1b) Do away with efi_arch_allocate_mmap_buffer() and 
> >> > use
> >> >    AllocatePages() uniformly, perhaps with a per-arch specified memory 
> >> > type
> >> >    (by means of which you can control whether the memory contents will 
> >> > remain
> >> >    preserved until the time you want to look at it). That will eliminate 
> >> > the
> >> >    only place_string() you're concerned about, with a patch with better
> >> >    diffstat (largely due to the questionable arch hook gone).
> >> >
> >> > However, this solution does not solve conflicts problem described in #1
> >> > because EFI memory map is needed during Xen runtime after init phase.
> >> > So, finally we would get back to #1. Hmmm... Should I check how Linux
> >> > and others cope with that problem?
> >>
> >> Ah, here you mention it actually. Yet you don't explain what conflict
> >> potential you see once using EfiRuntimeServicesData for the allocation.
> >
> > Good point! IMO, if crash kernel region conflicts with EfiRuntimeServices*
> > then we should display warning that it cannot be allocated. By the way,
> > once you mentioned that you have in your queue (I suppose that it is
> > extremely long) kdump patch which adds functionality to automatically
> > establish crash kernel region placement. I think that could solve (at
> > least partially) problem with conflicts. Could you post it?
>
> For one, unless asked to be at a specific location, we already dynamically
> place that area. The patch that I believe you think of just enhances the

Hmmm... I do not know why I always thought that it is not supported in Xen.

> placement to have something between "fully dynamic" and "at a fixed
> place". I've never posted it (or even ported it to -unstable) because I've
> never got positive feedback on it by those who it was originally created
> for. If you think it could be useful, I can certainly revive it.

Once again, thanks for doing that.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.