On Thu, Mar 14, 2024 at 04:30:05PM +0100, Jan Beulich wrote: > On 14.03.2024 15:33, Roger Pau Monné wrote: > > On Thu, Mar 14, 2024 at 09:51:22AM -0400, Jason Andryuk wrote: > >> On 2024-03-14 05:48, Roger Pau Monné wrote: > >>> On Wed, Mar 13, 2024 at 03:30:21PM -0400, Jason Andryuk wrote: > >>>> @@ -234,6 +235,17 @@ elf_errorstatus elf_xen_parse_note(struct > >>>> elf_binary *elf, > >>>> elf_note_numeric_array(elf, note, 8, 0), > >>>> elf_note_numeric_array(elf, note, 8, 1)); > >>>> break; > >>>> + > >>>> + case XEN_ELFNOTE_PVH_RELOCATION: > >>>> + if ( elf_uval(elf, note, descsz) != 3 * sizeof(uint64_t) ) > >>>> + return -1; > >>>> + > >>>> + parms->phys_min = elf_note_numeric_array(elf, note, 8, 0); > >>>> + parms->phys_max = elf_note_numeric_array(elf, note, 8, 1); > >>>> + parms->phys_align = elf_note_numeric_array(elf, note, 8, 2); > >>> > >>> Size for those needs to be 4 (32bits) as the entry point is in 32bit > >>> mode? I don't see how we can start past the 4GB boundary. > >> > >> I specified the note as 3x 64bit values. It seemed simpler than trying to > >> support both 32bit and 64bit depending on the kernel arch. Also, just > >> using > >> 64bit provides room in case it is needed in the future. > > > > Why do you say depending on the kernel arch? > > > > PVH doesn't know the bitness of the kernel, as the kernel entry point > > is always started in protected 32bit mode. We should just support > > 32bit values, regardless of the kernel bitness, because that's the > > only range that's suitable in order to jump into the entry point. > > > > Note how XEN_ELFNOTE_PHYS32_ENTRY is also unconditionally a 32bit > > integer. > > > >> Do you want the note to be changed to 3x 32bit values? > > > > Unless anyone objects, yes, that's would be my preference. > > As mentioned elsewhere, unless the entire note is meant to be x86-specific, > this fixed-32-bit property then would want limiting to x86.
Elfnotes are used only on x86 so far. I don't see why if/when another architecture wants to use the same elfnotes names with different field sizes that would be an issue. When such a need arises we could clarify that 32-bit size is only for x86 and also specify the size for the other architecture. Thanks, Roger.
