Message ID | f52befc9-f19c-12fb-b0db-b6c4219999b2@suse.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [v2] x86/PV: ignore PAE_MODE ELF note for 64-bit Dom0 | expand |
On Tue, Apr 04, 2023 at 11:19:08AM +0200, 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. > > Note that no known users exist that would have developed a dependency on > the bogus magic string. In particular Linux, NetBSD, and mini-os have > been checked. > > Fixes: 460060f83d41 ("libelf: use for x86 dom0 builder") > Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com> > --- > RFC: While Linux works fine with the adjustment, I'm not entirely > certain of external tools (crash?) 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 engaged, 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 (in not mentioning this VM- > assist aspect). Will look at it now. Thanks, Roger.
On 04/04/2023 10:19 am, 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. > > Note that no known users exist that would have developed a dependency on > the bogus magic string. In particular Linux, NetBSD, and mini-os have > been checked. > > Fixes: 460060f83d41 ("libelf: use for x86 dom0 builder") > Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
--- 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. Note that no known users exist that would have developed a dependency on the bogus magic string. In particular Linux, NetBSD, and mini-os have been checked. 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 (crash?) 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 engaged, 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 (in not mentioning this VM- assist aspect). --- v2: Extend description.