[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: Julien Grall <julien@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 7 Sep 2021 11:24:37 +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=92ya5n/p8bGdMWSZW+gUJtmHj66H2FVO1aSkxTQSLw4=; b=h7S+x70DHmBh76ah0GwTyHqR+dRxkrb1+iJZBBYadrJTUly4NEMHQV1ARKb75e/hcUAkTt2TkuTh03PnvuaXrbULUCWVEIa4zZaMf+h3kWsqCIAybCCOxKqQfSw25BugGDZCxvuR+tWoRKqfEhBB+qMv8KMa4C5zMp91KF4TVXeaulCWc3NPNRCgk7+ksg0s3J5nsXTKNlZ6qOZwpsFHdcT6WESKaf4L/q7XiKwMBw4/XFfm/JHefzdFKryRIe3UEbdiVB1DIsC0gMd4wqj+jjLDlh1imh+842GF/BC659oLPxtrJnVWh+CL9gLCUXcOopoFjlG2YQ+BG9aJyaUqXw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SoCUmH7KES2lcCuH28BWCZKl6vv2eWfI4HT8dr0g/0nO7odmgcFf73a1vWyY/QFbloxiHlu/o+d0vlQSBVX4LZEvflsPxUpmlwl/0uC51RhmDyLKqUeQuI7BCEebM6t9EgdP41pRPXSxYj30li/EUSHICh5qiCp9JU+OXpaIdcU5yEGCaXDgNtjrSApw0cV5lZ8EgdilziI3rLLqn5ZpQxBg8BhDyZSqRTmwT78tx6qIagR0zevvkKpqAC39hG2wpguJRw3nmnA/HMYh/TIVDXZlJwFFVOvby/dxCyzB3mrcpensH3ChPuU6tpjpF8l+7brB+f+4FzfPK1Iehy9Ffg==
  • Authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=suse.com;
  • Cc: 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, Luca Fancellu <luca.fancellu@xxxxxxx>
  • Delivery-date: Tue, 07 Sep 2021 09:24:51 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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=".

>> 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).

Jan




 


Rackspace

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