[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 2/2] xen: Populate xen.lds.h and make use of its macros


  • To: Michal Orzel <michal.orzel@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 30 Mar 2022 13:57:21 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LOSFShrkaiYP4CP6OEy4umetxHbuHPZerAGZnJ/sr+o=; b=O7Pi5UlqA6VM90E4Oy5ndOHCDZ81YMYQExN9LT8u+Bvn3ulvnOa/5plP4gSs1x46LVx0ick+tXdCzhavmvb3+bVGR2k41dO+58xGHp5bYklaY1O7ksmPUYAOF202C5ON5OOh2LkQLRdQ1vuEBEMwTFBNmp5Qcyev4wr1j4HMjCUVdp3LtYIeDqRfrmpbW9y+onYOEwB/RgiMfTdzbyQDg2ZXozg3r3ojuwx9ADrLOPIRhlKRqtSbz/rV8JnF2xceyd4cf+5zd1byaCEK0d/8N0599FhIR/22F+JNKmG90WMNqsnrI6OKsHmv1fWMa7U0OfYUSDmNoMHKy7x3XCprkw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a7sBEX7PIQ6SS1v+qqhjRS/bMwQYlwbCO+Ve8kd7fiATWpoMvrA/jODOu77+sjU2/v0YOiD2G7FH+/da5hCoKo6OdrhkMT+Eb/RajF1gYM5Gc/K8JP+oNefWIqIue3TlbzrC85G3ONUNeLenHK2nlCaa7pXTDzngA2BQIZuCgO6y7QemUwxdumQWkzcVHSilaWx1NuIPybts1zBwc7ev9T6v6MR9RYHSujarBc1nDQOK9lXFhPW9UAJuUHdEjC96KYHdOWH3CtTkHMVy2FfiKIpKp21K32or4Jf7OhvW4+yHwACR57EVYbxLzuCTBUsKHjN8DhJWQ3bjOyEKsTjH5g==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, Julien Grall <julien@xxxxxxx>
  • Delivery-date: Wed, 30 Mar 2022 11:57:48 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 30.03.2022 13:04, Michal Orzel wrote:
> Hello,
> 
> On 30.03.2022 12:42, Jan Beulich wrote:
>> On 30.03.2022 12:32, Julien Grall wrote:
>>> On 29/03/2022 12:42, Jan Beulich wrote:
>>>> On 29.03.2022 12:54, Julien Grall wrote:
>>>>> On 29/03/2022 11:12, Michal Orzel wrote:
>>>>>> On 29.03.2022 11:54, Julien Grall wrote:
>>>>>>> On 22/03/2022 08:02, Michal Orzel wrote:
>>>>>>>> --- a/xen/include/xen/xen.lds.h
>>>>>>>> +++ b/xen/include/xen/xen.lds.h
>>>>>>>> @@ -5,4 +5,104 @@
>>>>>>>>      * Common macros to be used in architecture specific linker 
>>>>>>>> scripts.
>>>>>>>>      */
>>>>>>>>     +/* Macros to declare debug sections. */
>>>>>>>> +#ifdef EFI
>>>>>>>
>>>>>>> AFAIK, we don't define EFI on Arm (just CONFIG_EFI). Yet we do support 
>>>>>>> EFI on arm64.
>>>>>>>
>>>>>>> As this #ifdef is now in generic code, can you explain how this is 
>>>>>>> meant to be used?
>>>>>>>
>>>>>> As we do not define EFI on arm, all the stuff protected by #ifdef EFI is 
>>>>>> x86 specific.
>>>>>
>>>>> I find the name "EFI" too generic to figure out that this code can only
>>>>> be used by x86.
>>>>>
>>>>> But, from my understanding, this header is meant to contain generic
>>>>> code. It feels a bit odd that we are moving arch specific code.
>>>>>
>>>>> To be honest, I don't quite understand why we need to make the
>>>>> diffferentiation on x86. So I guess the first question is how this is
>>>>> meant to be used on x86?
>>>>
>>>> We produce two linker scripts from the single source file: One (with EFI
>>>> undefined) to link the ELF binary, and another (with EFI defined) to link
>>>> the PE/COFF output. If "EFI" is too imprecise as a name for the identifier,
>>>> I wouldn't mind renaming it (to PE_COFF?), but at the same time I'm not
>>>> convinced this is really necessary.
>>>
>>> Thank for the explanation (and the other ones in this thread). You are 
>>> right the confusion arised from "generating" vs "linking".
>>>
>>> Renaming to PE_COFF may help to avoid the confusion with CONFIG_EFI. 
>>> That said, it would possibly make more difficult to associate the flag 
>>> with "linking an EFI binary".
>>
>> Indeed. And EFI_PE_COFF is getting a little unwieldy for my taste.
>>
>>> I think some documentaion about the define EFI would be help so there 
>>> are no more confusion between CONFIG_EFI/EFI. But I am not sure where to 
>>> put it. Maybe at the top of the header?
>>
>> That's perhaps the best place, yes.
>>
> In this case how about the following comment at the top of xen.lds.h:
> 
> "To avoid any confusion about EFI macro used in this header vs EFI support,
> the former is used when linking a native EFI (i.e. PE/COFF) binary, whereas
> the latter means support for generating EFI binary.

No, that's the case on Arm only. As Julien suggested, it is perhaps best
to explain the difference between EFI and CONFIG_EFI, without going into
arch specifics.

Jan

> Currently EFI macro is
> only defined by x86 to link PE/COFF output, however it is not unique to this
> architecture."
> 
> Cheers,
> Michal
> 




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.