[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 2/3] x86/boot: Reuse code to relocate trampoline
On Mon, Oct 7, 2024 at 10:47 AM Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote: > > On 07/10/2024 10:04 am, Jan Beulich wrote: > > On 07.10.2024 10:15, Frediano Ziglio wrote: > >> On Mon, Oct 7, 2024 at 9:07 AM Frediano Ziglio > >> <frediano.ziglio@xxxxxxxxx> wrote: > >>> On Mon, Oct 7, 2024 at 8:03 AM Jan Beulich <jbeulich@xxxxxxxx> wrote: > >>>> On 05.10.2024 15:21, Andrew Cooper wrote: > >>>>> On 05/10/2024 9:02 am, Frediano Ziglio wrote: > >>>>>> --- a/xen/arch/x86/boot/Makefile > >>>>>> +++ b/xen/arch/x86/boot/Makefile > >>>>>> @@ -1,6 +1,6 @@ > >>>>>> -obj-bin-y += head.o cbundle.o > >>>>>> +obj-bin-y += head.o cbundle.o reloc-trampoline.x64.o > >>>>> Ah. I think the $(obj)/%.x64.o rule you had in the previous patch wants > >>>>> introducing here. > >>>>> > >>>>> That said, x64 is the one name for 64bit that we reliably don't use. > >>>>> Also... > >>>>> > >>>>>> -head-bin-objs := cmdline.o reloc.o > >>>>>> +head-bin-objs := cmdline.o reloc.o reloc-trampoline.o > >>>>> ... head-bin-objs isn't really correct now seeing as they're not > >>>>> binaries in head.S. Also ... > >>>>> > >>>>>> nocov-y += $(head-bin-objs) > >>>>>> noubsan-y += $(head-bin-objs) > >>>>> The no$(foo)'s needs extending to the 64bit objects too. They're also > >>>>> used early enough to explode. > >>>>> > >>>>> In Xen, 64bit objects are the norm, and it's 32bit ones which are the > >>>>> exception, so how about we special case *.i386.o instead. Then > >>>>> > >>>>> obj32 := cmdline.i386.o > >>>>> obj32 += reloc.i386.o > >>>>> obj32 += reloc-trampoline.i386.o > >>>> I'd like to advocate for ix86 or i686. i386 gives a wrong impression imo. > >>> Why not simply x86 ? We already use it. > >>> > >> Looking at current files, we also use (to distinguish more clearly 32 > >> and 64 bit) x86_32. > > Either would be fine with me; as to x86 I took it that Andrew wanted to > > express the 32-bit-ness, which x86 alone doesn't unambiguously do. > > On further thought, why not just foo.32.o ? > > That should be clear enough. > > ~Andrew At this point, it starts to be more of a personal preference. I slightly prefer x86_32 looking at file names and Makefile's macros. Pick one. Frediano
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |