decui_microsoft.com added inline comments.
INLINE COMMENTS
> marcel wrote in copy.c:79-84
> Please also handle existing allocations. If those allocations represent
> free/usable memory after boot services has exited, then they are for all
> practical purposes "conventional memory".
>
> Also: please make sure that KERNEL_PHYSICAL_BASE is covered by usable memory
> to begin with.
>
> As such, we may have multiple memory descriptors that overlap with
> [2MB..2MB+nr_pages*PAGE_SIZE]. As long as they are free to use after boot
> services has exited, we're ok. We can only reduce the staging size if
> [2MB..2MB+delta] is usable when [2MB+delta..2MB+nr_pages*PAGE_SIZE] isn't.
> We can reduce the staging area to delta/PAGE_SIZE. But if 2MB isn't usable,
> we cannot reduce (or put differently we have to reduce to 0).
Do you mean the existing allocations of the type EfiLoaderData?
IMHO, after boot services has exited, we can only write the memory of
EfiLoaderData or EfiConventionalMemory. It's unsafe to write to memory of the
other mem types.
In case 2MB isn't usable, IMHO the OS can't boot, since it's designed in the
lds script that the kernel must begins with 2MB.
The current patch has made sure KERNEL_PHYSICAL_BASE is covered by a
EfiConventionalMemory mem block.
So, IMO the new algorithm can be:
for each mem block:
if mem is not EfiConventionalMemory && mem if not EfiloaderData
continue;
if mem doesn't contain 2MB
continue;
mem1 = mem;
mem2 = mem1++; //i.e. next mem block's descriptor
while (mem2 is EfiConventionalMemory || mem2 is EfiloaderData)
if mem1.end == mem2.start {
++mem2;
++mem1;
} else {
break;
}
break;
////now we know [mem, mem1] contains no hole and the range's type is
EfiConventionalMemory, or EfiLoaderData.
////figure out available_pages
////reduce nr_pages if nr_pages is > available_pages.
This seems too complex to me and according to the screenshot in the bug,
the amount of EfiLoaderData memory is actually small and it's not adjacent to
the EfiConventionalMemory block that covers 2MB.
So, if my above understanding is correct, IMHO we'd better leave the current
simple algorithm as-is?
REVISION DETAIL
https://reviews.freebsd.org/D9686
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: decui_microsoft.com, imp, jhb, will, kib, delphij, emaste,
sepherosa_gmail.com, honzhan_microsoft.com, howard0su_gmail.com, marcel
Cc: freebsd-virtualization-list
_______________________________________________
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virtualization-unsubscr...@freebsd.org"
