Re: input/output error _at_boot

> On 9. märts 2017, at 8:00, Dexuan Cui <decui_at_microsoft.com> wrote:
> 
> Hi Roberto, 
> Thanks for sending me your memmap and this is a temporary workaround
> patch for you:
> https://github.com/dcui/freebsd/commit/0edd1db55fbbb56352d6024250e4ae7dd8ad31e3.patch
> 
> I put the memmap info here for people who're interested:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746#c26
> 
> We can notice there is a 4MB BootServicesCode range at [12MB, 16MB) .
> loader.efi just writes into this range by force -- this is unsafe anyway!
> 
> To fix this correctly & thoroughly, IMO we need a relocatable kernel, but
> that would require a lot of complicated long term work:
> https://reviews.freebsd.org/D9686?id=25414#inline-56969
> 
> For now, I suggest we should only apply the idea "reduce the size of the
> staging area if necessary" to VM running on Hyper-V, we should restore the
> old behavior on physical machines since that has been working for people
> for a long period of time, though it's  potentially unsafe.
> 
> I think in the loader we can use CPUID to tell if we're running on Hyper-V or not.


IMO there are multiple issues around this problem and workaround.

First of all, to control UEFI memory allocation, the AllocatePages() has options:

AllocateAnyPages,
AllocateMaxAddress,
AllocateAddress

On x86, we use:

        staging = 1024*1024*1024;
        status = BS->AllocatePages(AllocateMaxAddress, EfiLoaderData,
            nr_pages, &staging);

Which means:

"Allocation requests of Type AllocateMaxAddress allocate any available range of pages whose uppermost address is less than or equal to the address pointed to by Memory on input.”

So, we are asking for an amount of memory (64MB), with condition that all the pages should be below 1GB.

And we get it. If hyper-v is in fact returning us memory from already occupied area - there can be exactly one conclusion - it is bug in hyper-v.

Note, this allocation method does *not* set the starting point for allocation, it can return us *any* chunk of memory of given size, below 1GB.

So the attempt to control such allocation by size, is unfortunately flawed - it really does not control the allocation.

Note that I have also seen AllocateAddress failures - there was nicely available chunk of memory, but the firmware just did not allocate with given address (it did happen with OVMF + qemu).

The secondary flaw there is also about firmware. Sure, with UEFI you can have “random” allocations and the actual control over memory is actually problem, but to plant an “egg”  in 1MB-1GB range, where you have most chances any OS will live - IMO this is just stupid.

The only real solution here is to either rise the MaxAddress limit or use AllocateAnyPages, get kernel loaded into the memory, and after switching off the boot services and before jumping to kernel, relocate the kernel to available location below 1GB… 

rgds,
toomas



> 
> Thanks,
> -- Dexuan
> 
>> -----Original Message-----
>> From: owner-freebsd-current_at_freebsd.org [mailto:owner-freebsd-
>> current_at_freebsd.org] On Behalf Of Dexuan Cui
>> Sent: Thursday, March 9, 2017 10:44
>> To: Roberto Rodriguez Jr <rob.rodz.jr9_at_gmail.com>
>> Cc: FreeBSD Current <freebsd-current_at_freebsd.org>
>> Subject: RE: input/output error _at_boot
>> 
>> [This sender failed our fraud detection checks and may not be who they appear
>> to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
>> 
>> Hmm, Alex did report 314891 worked.
>> 
>> Can you please post the full boot log of the loader?
>> Especially, when you see the “OK” prompt, can you please run the “memmap”
>> command like this link ...
>> 
>> You can take a photo of the screen and send it to me, if it’s too big.
>> 
>> Thanks,
>> -- Dexuan
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"