[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: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Luca Fancellu <luca.fancellu@xxxxxxx>
  • Date: Tue, 7 Sep 2021 12:33:47 +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; bh=MCCMeL6Eftx+YuUav1pGAJzgOA0UT56Kr+WzuuB4RWM=; b=TxvVrqZSbtTtWbkjFK3Cnay1kB5MTmSqkFKu1BMz37EU4NebkEmeDvsxwY2f0oqRpqKk6lx98rxUOrh2NvEyj9h3L8sFobZTitwq7x24n1bbRA8zBH+t3RD20IJhCXJn5MQBEMCRMtSj0Aa6UnNH3OUgtv3hgjhd1Z3LXz3AwBBS5dQPIWytIHnfMiHu/FA+ZfA7ttDcTBT/DCG/cZAKoXIRfY6dXv1XM0UGwaeqxwYx0v0pa2yspK5vo73Vvf5Afwj3frug1rYZPddHANIGk+W0ncAN1WkOu+vHsJjPS65HXXuh6iMS0Iyq9EJo7QaXkRrOsGBeURwdIGJmCckdtQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FctFGljTKHwoIn+RkMW29m+bJRD25ctBnAZGlAnZ8q4S0yrH9O3pCruloZuPa1PmiBxzIOwd7nGy4tQi9tsiTcH6CHLwxt3Kof2BYlYvOvTIRjiYHd+tD1T6BkukXuVOF8qVsEFgYU+gbnaz+kF7A7ov4+UEefdat21XGEYeCbV4CHtwlY/lf1iHWEz3crkB7A/v2E4kLFoTOz5NFyzepXNKD1P/OT642Jf7LHAqfVEDB0pY+2l+7SahLRTrYBJrhzdQ3+NTca7LYtpEUSHHSksUHVhMb2kjScypJ1MD0VeAaoiKdTsVMSK/QRuS0fd6IyqnngTujc8qfE8Ub+UtMA==
  • Authentication-results-original: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=arm.com;
  • Cc: Julien Grall <julien@xxxxxxx>, 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>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 07 Sep 2021 11:34:31 +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 7 Sep 2021, at 10:24, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> On 07.09.2021 11:17, Julien Grall wrote:
>> On 07/09/2021 09:33, Jan Beulich wrote:
>>> I'd like to suggest a different scheme, not the least because I expect
>>> the individual domains being independent of e.g. hypervisor command
>>> line options or Dom0 kernel versions. Yet varying sets of these are,
>>> for example, a reason to have multiple sections in the current scheme.
>>> Every dom0less guest would then require spelling out in every such
>>> section. Hence I think we'd be better off having a section per guest:
>>> [guest1]
>>> kernel=Image-domu1.bin console=ttyAMA0 root=/dev/ram0 rw
>>> property=cpus=1
>>> property=memory=0xC0000
>>> dtb=domu.dtb
>> I much prefer the idea of the section. This is going to be easier to 
>> parse the configuration file as we would not have to look for "domuX_" 
>> and then distinguishing X.
>>> These sections would then be referenced by other sections, e.g. by a
>>> new "guests" (or "domus", but this ends up looking a little odd for
>>> its matching of an unrelated latin word) keyword:
>>> guests=guest1,guest2
>>> If it is deemed necessary to make sure such a section can't be
>>> (mistakenly) used to create Dom0, such sections would need identifying
>>> in some way. Presence of property= (or, as per below, properties=)
>>> could be one means (allowing an empty setting would then be desirable).
>> I would expect dom0 to be described in the similar fashion at some 
>> point. So maybe we should name the property "domains=...".
> Not sure - the order above doesn't mandate domain IDs, yet Dom0 needs
> creating with ID 0. IOW I was deliberately suggesting "guests=".

Hi Jan, Julien,

Thanks for your feedbacks, really appreciated, I agree with you that sections
are easier to read.
I stand with the “guests=“ or “domus=“ or “domu_guests=“ keywords where
the references to “guest sections” can be listed, separated by commas. 

>>> As to the properties, is there anything wrong with having them all on
>>> one line:
>>> [guest1]
>>> kernel=Image-domu1.bin console=ttyAMA0 root=/dev/ram0 rw
>>> dtb=domu.dtb
>>> properties=cpus=1 memory=0xC0000
>> It depends on the number of properties for the domain, this may become 
>> quickly unreadable.
>> But... if we use sections, then I think it would be better to have:
>> kernel=..
>> dtb=...
>> cpu=1
>> memory=0xC0000
>> This would also allow us to create more complex setup (such as for the 
>> static memory allocation).
> If that's feasible parsing-wise - sure. I was first thinking to suggest
> separate keywords, but then decided there was a reason this wasn't done
> in the original proposal (with respective dom#_ prefixes).

Yes I think it is feasible and easy to read, so given your feedback we can 
agree on
something like that:


options=[xen command line]
kernel=[dom0 kernel file] [domain 0 command line options]
ramdisk=[dom0 ramdisk]
xsm=[xsm filename]
dtb=[xen device tree blob]

kernel=[domU kernel file] [domU command line options]
dtb=[domU passthrough dtb]

This won’t break the compatibility because on older version the domu_guests 
Is ignored, the user needs just to check that a guest section is not specified 
as default=
argument because in this case it will be loaded as dom0 kernel (and probably 
won’t work),
but I think we can just update the documentation to highlight this thing.

Finally this example should load a dom0less system:


# Xen boot arguments
options=noreboot console=dtuart dtuart=serial0 bootscrub=0
# Xen device tree
# domus to be started

kernel=Image-domu1.bin console=ttyAMA0 root=/dev/ram0 rw

kernel=Image-domu2.bin console=ttyAMA0 root=/dev/ram0 rw

> Jan



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