| Message ID | c5458448-10fe-9c04-f25e-b69704c5f3eb@suse.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | x86/PV: ignore PAE_MODE ELF note for 64-bit Dom0 | expand |
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
--- 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;
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.