[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: Luca Fancellu <luca.fancellu@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 1 Oct 2021 16:22:31 +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=XLNmfXCum9NOo3tqNOI002MiiiM9/ogQsZzO6YqF58M=; b=j9kn86gy5WE2DONtlm9TNJbuEcwxUfretty0SpN36ODrzTFYbh7nacQd2AFE06zxzwVLFsoUjg9a1Rz7Wn94PuwFoAKD70xJFgYdAGNiM58GLxLrS1jWznCH73Aov8ZSaYL5cn5LmsSQjjP0wnr1PC4HRFKdTjViC3Gpkb9agIooMYoRd0ENU6q7y7bBwacBo58xZ+afdRfVgE2mxOwFXEYDFvCI4/5/kQC9mew9Rjm9iu5dziJuAn91VgXRngesJjUg+FDlLicxyP2W1ipmZRlCAWLSGK03q/982t2mihbJbNBf8KZDt+lzLyc0e4wFsfS5iIETGu5PdVAlgsMS+w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mBvpjqnJJHStY6I2pA1JrffE+VkYwtB1Ar7BoN+wSpeWxm7B/hkj9CFgWJeGsnhZJZ5HQGdrQ3ipCPWWFd1CHwOfvEupQ6fmjs7G+DDUt6t4LM+Bh9NeAp6SvRiUA8aB+0oqcH4dcI+cY2KeC1cQCEINp/v/sGrMb88zUhEo+n10gtKbD855vlSAAwseu0ydAdf0rxJp/Q9PzKmYy/mToXiKJDzfVOReySnanl2z2bBepn1LJbXLSYZIpp84l09U8CqTFKwMkva0lqqjTkJsXoaZJZtKc5YHW9zB0yC76UsRk0ZiTpDcw8WgZxhJUiEf9WcNgpnWZ4r/nZrPDsTCtw==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.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 14:22:40 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.

Jan




 


Rackspace

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