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

Re: [RFC PATCH] xen/design: Add design for EFI dom0less system start


  • To: Luca Fancellu <luca.fancellu@xxxxxxx>, Julien Grall <julien@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 7 Sep 2021 13:55:45 +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; bh=El/+PteE+bpQXJfC9/uVNmt0qBNzA8BbA4wrelc4lus=; b=ZTLQm2R56q9GPneKd1KXybi6fdmqRkxgmTxi3UJzLhRXBVJQxKj/wdF55BuNUfs/qKomxV6iRspV4ulSLh9hD0yUgI3IzQ91k6Eq5Ug4iWua26UP0CmFiJ7+V+hH5Sdu8/BkeYI0HrRe0U4LPwKsRz4HQBwWnxQ9J6Uy2kc/1K+OfZueC+I1xZaakpnT4mFM5YRDmgrdthJIbxktvLv2opkk+KD3uEkmQaIrr/y7h6utFoKzlLgMK/molJ2TNkrdp4LZZBJpOO9XIvUTCXak/h4uZuzVhoWZV8oNtFRD5trg0v/k3wfbG0axYKkzEbmADPEXIwfsnzK/HKNSEJKQ7g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SNtz/WSoQrRC2vFAqRm/r0p0w0pmeSD8daRRk8vzoeWxNrv7J7tsSCT2H5AtPrqJQMjyJltfYhSZap01pBZQg1WglzcgJofInP2LnWCGtOCbZT9co6YQQSCLzgHwZdBGhnnDWloBxm0U/70rb7oo+wkbs2BLG3qKUhHv272T4xrbAACMancs4SZR04xM6Mw7scLwdn5h+dRcmEs0QBBfLAwHJZPeVH+HxrFSV3Lg1GhOZfE1x5if3WDzyv08WYDiUfPwC1ZgBN5Nt/4KkKLiSAp9SzC6YvpGWBOz9HbCVqxzVusY6gu2PLT3PjL/BmpvfpqVQDVjsLSMt60ZyiiF9A==
  • Authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=suse.com;
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Bertrand Marquis <bertrand.marquis@xxxxxxx>, wei.chen@xxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Tue, 07 Sep 2021 11:55:54 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 07.09.2021 13:51, Luca Fancellu wrote:
>> On 7 Sep 2021, at 10:35, Julien Grall <julien@xxxxxxx> wrote:
>> On 07/09/2021 07:52, Luca Fancellu wrote:
>>> --- /dev/null
>>> +++ b/docs/designs/efi-arm-dom0less.md
>>> @@ -0,0 +1,105 @@
>>> +# Xen EFI configuration file
>>> +
>>> +The current configuration file used by Xen when it is started as an EFI
>>> +application is considering only the dom0 guest and doesn't have any
>>> +property to describe and load in memory domU guests.
>>
>> From my understanding, the problem is less about properties (we already have 
>> them in the Device-Tree) but more about where are the binaries located in 
>> memory as we don't know in advance.
> 
> I think I used the wrong word there, I meant “keyword” instead of “property” 
> because I was referring about the
> lack of keywords to describe a domu guest in the Xen EFI configuration file.
> 
> I agree with you that on systems with static allocation, the kernel and 
> ramdisk binaries must be at certain locations
> that are out of control when we use the EFI boot services, the thing we can 
> do is provide a keyword to specify the
> addresses and then use the CopyMem() function to relocate the kernel/ramdisk 
> in the address we want.
> 
>>
>> So I would like to propose something that build on top of the Device-Tree 
>> work we did. Note this is early thoughts.
>>
>> The problematic nodes in the DT are:
>>
>>        module@0x4a000000 {
>>            compatible = "multiboot,kernel", "multiboot,module";
>>            reg = <0x0 0x4a000000 0xffffff>;
>>            bootargs = "console=ttyAMA0 init=/bin/sh";
>>        };
>>
>>        module@0x4b000000 {
>>            compatible = "multiboot,ramdisk", "multiboot,module";
>>            reg = <0x0 0x4b000000 0xffffff>;
>>        };
>>
>> In particular the property "reg" cannot be known in advance because the UEFI 
>> stub will be responsible to load the binaries in memory.
> 
> Yes that’s true, the UEFI stub is using from the UEFI boot service the 
> AllocatePages function that is giving back an address out of our control,
> then using another function the binary is read from the disk and copied at 
> that address, finally the UEFI stub is writing the node in the device tree 
> that
> will be used by Xen later.

If you know the intended address is available, AllocatePages() can very well
be given a pre-determined address via the AllocateAddress allocation type.

Jan




 


Rackspace

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