[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |