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

Re: [PATCH] xen/efi: Fix Grub2 boot on arm64


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Luca Fancellu <luca.fancellu@xxxxxxx>
  • Date: Wed, 3 Nov 2021 14:09:23 +0000
  • 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=+dYgUg7d63m2iBJ+XArd9kOVG29rPtTAgO0RXVt7Wl4=; b=W6URkwjVLyDvlB0sldnMr0UJOUj7f+37JzSVafy/OBiTIhyWwMdt/794F+6gKwgiOUXZNagsRvB2IehyPc3Lf2gZ3r+3QSgwg05+sE7ASlLvFQR79U+1wS1Bg4Z03nbuyHnO0MSj4fmDr8bYqrpX1RCxaw63aHFJDHyMPDd0/bIqykor6CIp00uuZkMtjIxByeapriKR6zXFkLNnz8KN2tMK1+kUmmr7kCVbZ6foxMX28kZXc9ZuBZv73BProMXDZK/5UzDUULbAQhkrPOLo1xKXuFDkC650f0F24s4zkHU7guSROgz9v5K35Q/lqsEun34qgyz3DzYHbqatTD7USw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dARUct/sL1Haa89C4wRCwcrFwVNlHstZYxfbTzi+TTDVM6DDLVHDFxHCCU26Dae7uLxy4FgRq7dmCmhXaTlgHZ46Mx1pmhYmHCiX/uwSXx+RzTZ7syaNA4TNcyADKYHStDVzy52j4deUfdsZgDmIY7g5OqVwWE3HxYsf8ODUlSJHJzuQ/HqsEqgprWqyduBs1armI14Nm2CPQSUJzaxz0jJJgObzZ0N5hevHpBJKPbI7wawJ9MWCjFDfOAoaU2lDgMsKv11Pn/wqvOM+nOPUVp9Ma3LBy4bGfgEx2A8X11IgrtTbsafPVwdrt502wVnaJtihZTWxPriHnHEqXWJg2w==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;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>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>
  • Delivery-date: Wed, 03 Nov 2021 14:10:08 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;


> On 3 Nov 2021, at 11:28, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> On 03.11.2021 11:20, Luca Fancellu wrote:
>> 
>> 
>>> On 3 Nov 2021, at 08:20, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>> 
>>> On 02.11.2021 18:12, Luca Fancellu wrote:
>>>>> On 2 Nov 2021, at 14:45, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>>>> On 02.11.2021 15:05, Luca Fancellu wrote:
>>>>>> The code introduced by commit a1743fc3a9fe9b68c265c45264dddf214fd9b882
>>>>>> ("arm/efi: Use dom0less configuration when using EFI boot") is
>>>>>> introducing a problem to boot Xen using Grub2 on ARM machine using EDK2.
>>>>>> 
>>>>>> The problem comes from the function get_parent_handle(...) that inside
>>>>>> uses the HandleProtocol on loaded_image->DeviceHandle, but the last
>>>>>> is NULL, making Xen stop the UEFI boot.
>>>>> 
>>>>> According to my reading the UEFI spec doesn't (explicitly) allow for
>>>>> this to be NULL. Could you clarify why this is the case? What other
>>>>> information may end up being invalid / absent? Is e.g. read_section()
>>>>> safe to use?
>>>> 
>>>> My test on an arm machine running Grub2 on top of EDK2 showed that
>>>> when Xen is started, the get_parent_handle(…) call was failing and stopping
>>>> the boot because the efi_bs->HandleProtocol(…) was called with the
>>>> loaded_image->DeviceHandle argument NULL and the call was returning
>>>> a EFI_INVALID_PARAMETER.
>>>> So the parent handle can’t be requested and the filesystem can’t be used,
>>>> but any other code that doesn’t use the handle provided by 
>>>> get_parent_handle(…)
>>>> can be used without problem like read_section(...).
>>> 
>>> I understand this. My question was for the reason of ->DeviceHandle
>>> being NULL. IOW I'm wondering whether we're actually talking about a
>>> firmware or GrUB bug, in which case your change is a workaround for
>>> that rather than (primarily) a fix for the earlier Xen change.
>> 
>> The issue was found only when using EDK2+Grub2, no issue when booting
>> directly from EDK2.
>> This is a fix for the regression, because without the EFI changes, Grub2 was
>> booting successfully Xen. Using grub2 to boot Xen on arm is a very common
>> solution so not supporting this anymore could lead to lots of people having
>> issues if they update to Xen 4.16.
> 
> I'm not objecting to addressing the issue. But the description needs
> to make clear where the origin of the problem lies, and afaict that's
> not the earlier Xen change. That one merely uncovered what, according
> to your reply, might then be a GrUB bug. Unless, as said earlier, I
> merely haven't been able to spot provisions in the spec for the field
> in question to be NULL.

Maybe I can rephrase to be more specific from:

The problem comes from the function get_parent_handle(...) that inside
uses the HandleProtocol on loaded_image->DeviceHandle, but the last
is NULL, making Xen stop the UEFI boot.

To:

Despite UEFI specification, EDK2+Grub2 is returning a NULL DeviceHandle,
that is used by efi_bs->HandleProtocol(…) inside get_parent_handle(…),
causing Xen to stop the boot getting an EFI_INVALID_PARAMETER error.

Do you think it can be ok like this?

Cheers,
Luca

> 
> Jan




 


Rackspace

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