From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4185FC5320E for ; Mon, 19 Aug 2024 09:56:05 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.779520.1189229 (Exim 4.92) (envelope-from ) id 1sfz7B-0004qY-4k; Mon, 19 Aug 2024 09:55:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 779520.1189229; Mon, 19 Aug 2024 09:55:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1sfz7B-0004qR-1T; Mon, 19 Aug 2024 09:55:53 +0000 Received: by outflank-mailman (input) for mailman id 779520; Mon, 19 Aug 2024 09:55:51 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1sfz79-0004qL-LF for xen-devel@lists.xenproject.org; Mon, 19 Aug 2024 09:55:51 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1sfz78-0000ix-PO; Mon, 19 Aug 2024 09:55:50 +0000 Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.0.211]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1sfz78-0005IB-IK; Mon, 19 Aug 2024 09:55:50 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=4TZOcAlEVvtZv36VJJaMzltq4oCXE3YQbOCGzPnK9Bg=; b=4gTb4z/s4LRQiP2c5KbeUAVFCX H3L9FTaKAVEk71Vycvq3qn5jIINhQQFlYAsZ6A66yLjSlL8JEZ12KMa8ZRZISh+HfGcQBpkiK99dW fWhzuXSJ9DLfdKDP3XJg2+oOVf7RGXyzxkEgRQeyq7trvknqg1JPCo6Tzsco1dolAC0Q=; Message-ID: Date: Mon, 19 Aug 2024 10:55:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/4] xen: make VMAP only support in MMU system Content-Language: en-GB To: Ayan Kumar Halder , Jan Beulich , Ayan Kumar Halder Cc: xen-devel@lists.xenproject.org, Penny Zheng , Wei Chen , sstabellini@kernel.org, bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com References: <20240813171356.46760-1-ayan.kumar.halder@amd.com> <20240813171356.46760-3-ayan.kumar.halder@amd.com> <6d333d94-80ad-485c-b024-a45a388b96a4@suse.com> <597b358e-3b45-4fba-922d-31208b55d15a@amd.com> <9fd1801c-1460-44e5-b066-f6da1167543b@xen.org> <1a328f00-3b0d-4e9c-856c-97c3a80dfdef@amd.com> From: Julien Grall In-Reply-To: <1a328f00-3b0d-4e9c-856c-97c3a80dfdef@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Ayan, On 19/08/2024 10:45, Ayan Kumar Halder wrote: > I am ok with this. This has the benefit that the change can be contained > within arch/arm if we do the following :- > > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c > index cb2c0a16b8..26f7406278 100644 > --- a/xen/arch/arm/setup.c > +++ b/xen/arch/arm/setup.c > @@ -329,7 +329,9 @@ void asmlinkage __init start_xen(unsigned long > boot_phys_offset, > >      setup_mm(); > > +#ifdef CONFIG_MMU >      vm_init(); > +#endif > >      /* Parse the ACPI tables for possible boot-time configuration */ >      acpi_boot_table_init(); > > Are we ok with this ? > > The definition of vm_init() is in xen/include/xen/vmap.h. If I enclose > it using any CONFIG_XXX (like I have done in the current patch), then I > need to introduce it in common/Kconfig and define it for x86 and PPC. I > would prefer to contain the change within arch/arm only if possible. Just to clarify, are you suggesting to just protect the call vm_init(). In other word, common/vmap.c would still be included in the final binary for the MPU? If yes, then I think it would be a bit odd... Someone could still call vmap() and this would not break until runtime. So I don't see how we could get away from modifying the common code. Cheers, -- Julien Grall