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 <jbeulich@suse.com>
---
RFC: While Linux works fine with the adjustment, I'm not entirely
     certain of external tools (kexec?) having grown a dependency. 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.

Prior to "x86/PV32: restore PAE-extended-CR3 logic" that (meaningless
for 64-bit domains) VM-assist could also be enabled, based on the ELF
note's value. I expect that change to go in first, at which point the
description here is going to be correct.

--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -459,8 +459,13 @@ int __init dom0_construct_pv(struct doma
     compat = is_pv_32bit_domain(d);
 
     if ( elf_64bit(&elf) && machine == EM_X86_64 )
+    {
         compatible = true;
 
+        /* Zap meaningless setting which kernels may carry by mistake. */
+        parms.pae = 0;
+    }
+
     if ( elf_msb(&elf) )
         compatible = false;

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 <jbeulich@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

On 15.02.2023 19:41, Andrew Cooper wrote:
> 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 <jbeulich@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).

I guess I really was thinking of something like "crash" instead, mixing
things up that way.

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

I.e. the same as (so far) upstream Linux.

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

Which kind of reads like an ack, except there wasn't any ...

Jan