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. 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...
