On 26.10.2023 12:31, Andrew Cooper wrote: > On 26/10/2023 9:34 am, Xenia Ragiadakou wrote: >> On 26/10/23 10:35, Jan Beulich wrote: >>> On 26.10.2023 08:45, Xenia Ragiadakou wrote: >>>> Given that start < kernel_end and end > kernel_start, the logic that >>>> determines the best placement for dom0 initrd and metadata, does not >>>> take into account the two cases below: >>>> (1) start > kernel_start && end > kernel_end >>>> (2) start < kernel_start && end < kernel_end >>>> >>>> In case (1), the evaluation will result in end = kernel_start >>>> i.e. end < start, and will load initrd in the middle of the kernel. >>>> In case (2), the evaluation will result in start = kernel_end >>>> i.e. end < start, and will load initrd at kernel_end, that is out >>>> of the memory region under evaluation. >>> I agree there is a problem if the kernel range overlaps but is not fully >>> contained in the E820 range under inspection. I'd like to ask though >>> under what conditions that can happen, as it seems suspicious for the >>> kernel range to span multiple E820 ranges. >> >> We tried to boot Zephyr as pvh dom0 and its load address was under 1MB. >> >> I know ... that maybe shouldn't have been permitted at all, but >> nevertheless we hit this issue. > > > Zephyr is linked to run at 4k. That's what the ELF Headers say, and the > entrypoint is not position-independent.
Very interesting. What size is their kernel? And, Xenia, can you provide the E820 map that you were finding the collision with? Jan > So trying to put the binary anywhere else is going to work about as well > having the notes section misalign the pagetables by 0x20 bytes[1]. > > ~Andrew > > [1] Guess what was causing the "Zephyr doesn't boot PVH" issues. Which > is doubly irritating because about 6h of debugging prior, I'd pointed > out that the linker was complaining about an orphaned section and that > that ought to be fixed before trying to debug further...
