Xen project Mailing List

Re: [PATCH v2 3/5] arm/dom0less: put dom0less feature code in a separate module

To: Stefano Stabellini <sstabellini@xxxxxxxxxx>

From: Luca Fancellu <Luca.Fancellu@xxxxxxx>

Date: Fri, 29 Sep 2023 07:15:48 +0000

Accept-language: en-GB, en-US

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=J1EtuaFbmtSfEpDKmW8UsU7lftlaVd1qVeGFCMqybMQ=; b=aZJm7RIX6Mjd0pPf+oj6b534dIBrA8tlkbgUr54Fc1QoHlIy1YTvXRqxzX5rOOLtlxmay3l3VqVKpShB690Sl7DsSjQzSiIPI4gbgyTjAyPeXc8EAODX0J00nPSKxT6MNg7DEcg1llK3/pV3nGdNPC0WvSIbHel68i0Q/v00qI0YAKYV4L65Mu5JSVlvHE1i2PHoSgA2vci4LHrfWQjougatG2R45Me/or7OB+W53qWjbHUt1wLTQm/eBwhvHGQyJQAEZy5TkuuSwiOzD0Bc/HcPtBoyZKeWIrCVLoxhmuMJK0cfYxiVGZpaayEkTmB6SERPIaIvfHlaTKksy6LEgQ==

Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aI95eU6cfSCZw5xBCCAFja9YkVY3wbOkf4kj2pDzGLDeAZu3d/+AjJK5830oIh1mnzc39gF42ZU3viJVgjelxc6ONuQJJvTkxyFt3pf05mtIvu2HhtqLHKiHjkWcdYbnNbLkVNycSEmHhZT3v9F1SLskbTNt11QiUu4IlnRRk8IPjD+hVf9SyVPiQdCVoetNYUnNL5UW4wnUy22NVRfv4Xjh1KNmWM9lfkucdte2V9YJikIsHodML5LpUmIQnboOVMmF4yaWZS1GYb+2Ay75pHPq8pJENfT/bGGeIdpQmwtm1U3BVxbEy6TKLawDoHMgjlPgSJsgR0dUNmyydW3xxQ==

Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;

Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Wei Chen <Wei.Chen@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>

Delivery-date: Fri, 29 Sep 2023 07:16:30 +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;

Thread-index: AQHZ8UtNgBNI2koBH0+cEATmTDiuOrAw9peAgABwTYA=

Thread-topic: [PATCH v2 3/5] arm/dom0less: put dom0less feature code in a separate module

Hi Stefano, > On 29 Sep 2023, at 01:33, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote: > > On Wed, 27 Sep 2023, Luca Fancellu wrote: >> Currently the dom0less feature code is mostly inside domain_build.c >> and setup.c, it is a feature that may not be useful to everyone so >> put the code in a different compilation module in order to make it >> easier to disable the feature in the future. >> >> Move gic_interrupt_t in domain_build.h to use it with the function >> declaration, move its comment above the declaration. >> >> The following functions are now visible externally from domain_build >> because they are used also from the dom0less-build module: >> - get_allocation_size >> - set_interrupt >> - domain_fdt_begin_node >> - make_memory_node >> - make_resv_memory_node >> - make_hypervisor_node >> - make_psci_node >> - make_cpus_node >> - make_timer_node >> - handle_device_interrupts >> - construct_domain >> - process_shm >> >> The functions allocate_static_memory and assign_static_memory_11 >> are now externally visible, so put their declarations into >> domain_build.h and move the #else and stub definition in the header >> as well. >> >> Move is_dom0less_mode from setup.c to dom0less-build.c and make it >> externally visible. >> >> Where spotted, fix code style issues. >> >> No functional change is intended. >> >> Signed-off-by: Luca Fancellu <luca.fancellu@xxxxxxx> > > This is great! A couple of questions. > > Why was allocate_static_memory not moved to dom0less-build.c ? My aim is to decouple the features, so in patch 4 we move (just once as Julien suggested) the static memory code on a module on its own, because we can have a guest booted with dom0less feature but having it with static memory is optional. > > Would it make sense to also move construct_dom0 to dom0less-build.c > given the similarities with construct_domU? I am not sure about this. > We can’t do that because the final goal of this serie is to have a Kconfig disabling dom0less, so in that case we will end up removing from the compilation also construct_dom0. Cheers, Luca

©2013 Xen Project, A Linux Foundation Collaborative Project. All Rights Reserved.
Linux Foundation is a registered trademark of The Linux Foundation.
Xen Project is a trademark of The Linux Foundation.