The 0xa0000 restriction applies to BIOS really... "matt@xxxxxxxxxxxxxxxxx" <matt@xxxxxxxxxxxxxxxxx> wrote: >On Tue, 18 Jun, at 10:12:22PM, Zachary Bobroff wrote: >> > Okay, I'm fine with that aspect then. Let's hope everyone plays by >> > that rule. >> This is all according to specification, so if they are not following >> these rules they should be corrected. The link to where the current >> public version of the specification is available is here: >> http://www.uefi.org/specs/agreement > >While I agree that the vendor should be informed if their >implementation >deviates from the spec in some way, the Linux kernel usually still >needs >to support these nonconforming machines once they end up in the hands >of >consumers (which is often the point at which we discover these kinds of >issues). Sadly, we're still not in a position where firmware updates >can >be applied from OEMs ubiquitously, either because machines are End of >Life'd or because the update needs to be run from Windows. > >We tend to adopt the approach of: let's try this until we get reports >of >a class of machines where this solution doesn't work. > >Though I do find it refreshing to hear engineers talking about the UEFI >spec in such black and white terms. That is certainly the ideal we >should be aiming for. > >> > Why by one? Splitting some 'free memory' block may result in an >> > increase by more then one afaict. Assuming the increment can only >be >> > one is >implying you having knowledge of the allocator >> > implementation and behavior, which shouldn't be made use of in >> > kernel code. >> We had to actually increment it by two to get it to work correctly. >> This is all based upon the use of the low_alloc routine in the linux >> kernel file. I agree there is still some outstanding issue based >upon >> this, but we put it through several different types of tests and it >> continued to work correctly. The truest solution would be to us the >> AllocateMaxAddress parameter when using AllocatePages. > >[...] > >> It was my understanding that the point of this was to allocate the >> memory map below a certain address in memory because the kernel >> required it. Matt, can you comment here? I am not aware of what >> address it needs to be below, but using this function should do the >> trick. Also, if you want to inform me better of what memory ceiling >> restrictions there are at this early stage of the kernel, I can >> rewrite the file without the need of the low_alloc routine entirely. > >The most important restriction is that all allocations in the EFI boot >stub need to be below the 1GB mark, because only the first 1GB of >virtual memory is mapped, unless certain flags are set in the >xloadflags >field of the boot_params header. See Documentation/x86/boot.txt. > >Further to that, I think I remember some restrictions on the location >of >the cmdline pointer - that it needs to be below 0xa0000. Again, >Documentation/x86/boot.xt should have all the info you need. -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html