On Tue, Jul 15, 2014 at 11:02:22AM +0100, Leif Lindholm wrote: > On Mon, Jul 14, 2014 at 02:40:48PM -0400, Mark Salter wrote: > > On Mon, 2014-07-14 at 17:25 +0200, Ard Biesheuvel wrote: > > > If we fail to relocate the kernel Image to its preferred offset of TEXT_OFFSET > > > bytes above the base of DRAM, accept the lowest alternative mapping available > > > instead of aborting. We may lose a bit of memory at the low end, but we can > > > still proceed normally otherwise. > > > > This breaks APM Mustang because the spin-table holding pen for secondary > > CPUs is marked as reserved memory in the TEXT_OFFSET area and the kernel > > placement using your patch makes it unreachable by kernel. Here is a > > patch I've been working with to solve the same problem: > > Hmm. The thing I don't like about the below approach is that it hard > wires in the "memory below TEXT_OFFSET cannot be used" aspect, beyond > the current prectical limitation. > > Since we are likely to see platforms with UEFI memory in use around > start of RAM, that is a limitation we should probably try to get rid of. This isn't just an issue for UEFI. There are other reasons one might want to load a kernel away from the start of RAM while still wanting to address said RAM(e.g. kdump). We should address that. [...] > > @@ -273,6 +282,10 @@ static void __init free_boot_services(void) > > continue; > > } > > > > + /* Don't free anything below kernel */ > > + if (md->phys_addr < PHYS_OFFSET) > > + continue; > > + > > Is the spin table area really allocated as BOOT_SERVICES_*? If that is the case, this platform is _broken_. The spin-table memory (both the code and the mailboxes) needs to live around forever in case you don't boot all of the secondaries. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
