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

Re: [PATCH v4 2/3] arm/efi: Use dom0less configuration when using EFI boot


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Luca Fancellu <luca.fancellu@xxxxxxx>
  • Date: Fri, 1 Oct 2021 16:13:37 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.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=m2nTysSJReSsS5P/E2b3SW9+rjjhEy4D2yd+3EaRrrk=; b=ck7z8BnRxrDgER1VRnnrgn4f/cktcrRUc8XgpPgSc3BsLlah9ZkS3cvZzhCr651p/xzNEWe3cy93xg2vd6yFa0wClRPChM3KYiQcaYBPeIPv4xEaYuaXye0BPaeYpTFU7wNRUadmPUDBvl4092d9GBkRfG58QnaBh/CJwYybAuyeDfwAxDm2pVF0KZaH9lySat2z5togUUWgETtUBkV1LxFDqP2MODLC+RNZZiiqAnfwbj54e2wFkheSKRo3E+GOPKiXbdzlK2Cxy9mZoM7RFxJOCXqSGRrYYumHp6UM4AvgLHXXYl0L89+IQT81GhnplMaZvMs8cZ35OjYNc22Aig==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZlX+HrW+YtUm7lbxcNzrDIl9j0g2jDAJ63OOniBpSvkYufkX3DZ11C47o/EO03W3RCbprQBBY2rN2Iyv1YQEvof1oIoZ+hW3O3ARniGbUzmaoIM1A2ekgxQXzERwQxgIRLW9b1Jy+r7dQ2x3cvwvI6d6rq1Oi7e87S7uuepXMWZQXP9LYQW9W05vxQH9HtSFlRz4uCIB5hImCaUqWqweCnwmmHcb6GG6nA1nRLRXVefsBMa1DyQiw7Oq9PSyhT5Lhzex0OHJdqQEsvPEuhL+tYPR2XJdmEYyKWY3yDvWxrPzpv6pGGSem4xcjg/s6nOp8LQGxtsqydsahPeCXizsuw==
  • Authentication-results-original: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=arm.com;
  • Cc: Bertrand Marquis <bertrand.marquis@xxxxxxx>, wei.chen@xxxxxxx, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 01 Oct 2021 15:14:16 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=arm.com;


> On 1 Oct 2021, at 15:22, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> On 01.10.2021 15:55, Luca Fancellu wrote:
>>> On 1 Oct 2021, at 12:02, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>> On 30.09.2021 16:28, Luca Fancellu wrote:
>>>> @@ -1361,12 +1361,30 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
>>>> *SystemTable)
>>>>        efi_bs->FreePages(cfg.addr, PFN_UP(cfg.size));
>>>>        cfg.addr = 0;
>>>> 
>>>> -        dir_handle->Close(dir_handle);
>>>> -
>>>>        if ( gop && !base_video )
>>>>            gop_mode = efi_find_gop_mode(gop, cols, rows, depth);
>>>>    }
>>>> 
>>>> +#ifdef CONFIG_HAS_DEVICE_TREE
>>>> +    /* Get the number of boot modules specified on the DT or an error 
>>>> (<0) */
>>>> +    dt_modules_found = efi_arch_check_dt_boot(dir_handle);
>>>> +#endif
>>> 
>>> So I had asked to add a stub enclosed in such an #ifdef, to avoid the
>>> #ifdef here. I may be willing to let you keep things as you have them
>>> now, but I'd like to understand why you've picked that different
>>> approach despite the prior discussion.
>> 
>> There must be a misunderstanding, your message in the v3 was:
>> 
>> "Every time I see this addition I'm getting puzzled. As a result I'm
>> afraid I now need to finally ask you to do something about this (and
>> I'm sorry for doing so only now). There would better be no notion of
>> DT in x86 code, and there would better also not be a need for
>> architectures not supporting DT to each supply such a stub. Instead
>> I think you want to put this stub in xen/common/efi/boot.c, inside a
>> suitable #ifdef.”
>> 
>> So I thought you wanted me to remove the stub in x86 (since it doesn’t 
>> support DT)
>> and put this call under #ifdef so it won’t be compiled for arch not 
>> supporting DT.
> 
> So FTAOD I'll repeat the crucial part: "I think you want to put this
> stub in xen/common/efi/boot.c". There was nothing about removing the
> stub altogether.

Oh ok, now I see, so in your opinion this is a better idea:

#ifndef CONFIG_HAS_DEVICE_TREE
static inline int __init efi_arch_check_dt_boot(EFI_FILE_HANDLE dir_handle)
{
    return 0;
}
#endif

But I would like to understand the advantage respect of my approach, could you
explain me?

Cheers,
Luca


> 
> Jan
> 




 


Rackspace

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