On 15/02/2023 3:10 pm, Jan Beulich wrote:
> Besides a printk() the main effect is slight corruption of the start
> info magic: While that's meant to be xen-3.0-x86_64, it wrongly ended
> up as xen-3.0-x86_64p.
>
> Fixes: 460060f83d41 ("libelf: use for x86 dom0 builder")
> Signed-off-by: Jan Beulich <jbeul...@suse.com>
> ---
> RFC: While Linux works fine with the adjustment, I'm not entirely
> certain of external tools (kexec?) having grown a dependency.
Again, I wonder why you think regular kexec has any anything to do with
this?
Are you mixing it up with (legacy) pvgrub which does end up doing a
kexec inside the context of a PV guest? If so, it's MiniOS's support
you need to care about, and I cant see any logic that even inspects the
start_info->magic[] (either in MiniOS itself, or the pvgrub patches).
Like plenty of other fields in the undocumented PV ABI, it's not
interesting at all to software. There's nothing I can see in it that
you don't know at compile time.
> It
> may be worth noting that XenoLinux and its forward ports never had
> this ELF note in 64-bit kernels, so in principle it may be
> reasonable to expect that no such dependency exists anywhere.
NetBSD sets PAE_MODE for 32bit and 64bit but, like everything else,
doesn't appear to inspect start_info->magic[].
xen-3.0-x86_64p is obviously bogus. I find it far more likely that
noone has ever noticed this bug, than anyone gaining a dependency on it.
Insert usual rant about the PV ABI being entirely undocumented...
~Andrew
