Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: [PATCH v2 9/9] xen/x86: adjust data placement
From:   Jan Beulich <jbeulich@suse.com>
To:     Juergen Gross <jgross@suse.com>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>
CC:     Stefano Stabellini <sstabellini@kernel.org>,
        lkml <linux-kernel@vger.kernel.org>,
        =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>,
        "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <9a26d4ff-80a1-e0c1-f528-31a8568d41f7@suse.com>
Message-ID: <8155ed26-5a1d-c06f-42d8-596d26e75849@suse.com>
Date:   Thu, 30 Sep 2021 14:21:13 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.14.0
In-Reply-To: <9a26d4ff-80a1-e0c1-f528-31a8568d41f7@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?n3v2wC5ga7QHVRb8OQ9O8FqR4sL5QZNRpApXIrP6j1D8BQlDxdiAmJO2y8sv?=
 =?us-ascii?Q?Ovr9V8EKikUP2virTtcCHm0R/jI6CnrYPhbchgFd3AKjuLKBgjKlR1AkzxiG?=
 =?us-ascii?Q?zB0x80WYEfIOevUqv2ZKfyObzWFr+ZMsCc9CfXXQ8rsAHsEzaP9N6RFaCNIH?=
 =?us-ascii?Q?HVQKJqfB9YYREx/NoV0BL471Fvz5HPxRbDrO9Xd0Zo51a6XNfqEZKUCHCKig?=
 =?us-ascii?Q?fv1ESpAQXkCAv1daFO3V+dST2sodgCUng5U6Q9Hgn+h+qihw4EZ6PjPEa2RR?=
 =?us-ascii?Q?WL/KpNa9StH/zH8KCyvEirT8Q74ankMr60ur9OLSIhP/FA8aRaO7P+kun5oX?=
 =?us-ascii?Q?aqDgdA10YLG252aBZz0mfq+pwptnMWAgm1c3n+SwvAF61yVAKpuZ2D9vM37Z?=
 =?us-ascii?Q?9oiNIBIcm3M3zM6vz83byONCttCAk/u7FY29WUnpLhEwsfWuUt1pAQ1Seoqy?=
 =?us-ascii?Q?DGywVgIOsSTGCy76a4cpOS83ODyYzGM6pMJUuT3lIsWLJz2ucjap5LP44SWK?=
 =?us-ascii?Q?Y1ZYVS6006SsldVSaPuCMSi3qHDYV4aiJOzZ++Yg4q0/5Q+geSbjDExUZz5v?=
 =?us-ascii?Q?BDafk7fmHzzb6G9y06sj0pCSqx367vDyVBGsLTm/LQduELx/wfINUdruUz5s?=
 =?us-ascii?Q?7xeI0k9qM5TuacIxzRDVc4/eZk5G2lIba7j2IhbSfZbDmqMWBa+4uL+E0uJI?=
 =?us-ascii?Q?Eqot2JPVh848Qy3/ryufn3Gx+lGHtDTCBPTnp5NhdBA4dfw/HksAliw+FFLl?=
 =?us-ascii?Q?0bVEjvDc6yXoY8n98dhfqVqz9Wgx9SsGKkPKaN+DVxYDbwLzpE9xBN1AKuor?=
 =?us-ascii?Q?upOlJa66fwZRTZNzXWS5sONbYhwvJ8GgGAuVK3hBgP4iaBd6y1qEoXarQ5/7?=
 =?us-ascii?Q?pmSAlRZVL7Da0shrQsQt9515M/rgdscmjsgj/GQcL53T3IS21pu6vUWd86+T?=
 =?us-ascii?Q?GcLfvTgAy/KiCK6ox7ls7YyRpTsx6sEzDGoUzO8ulisBoTjMbkqEjf+3aoLl?=
 =?us-ascii?Q?XXHxA4Knd2rcZ5cNbSKy4zvxK/CVX/3yg0mvl0d5jwC6G23nqDP+Iv/QfaJ2?=
 =?us-ascii?Q?QCmKHF9njCVemqBnxI82LJnZtOt3MXlrzk7rNf2T4gBsEu7FvHZpdE3T+scb?=
 =?us-ascii?Q?9txd1aG10c8XElBbt8J+zE/yUl1UIvZuWm9XMyvI5gzpr4peQSLjukzMEH99?=
 =?us-ascii?Q?nJGjvRg719HQdxBVFc4Spgimj9tzI07BFEzRt683yv0hFBAU8n20mbXwUHmm?=
 =?us-ascii?Q?nHwy8Hl7av2rc7iqzOF7K6MkR4COiRF9mdLUwbMhkf/SFF8IPEH5xXV799xG?=
 =?us-ascii?Q?d+qZzfweJ4CSpxNZ7wVY4GAB?=
X-OriginatorOrg: suse.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4aa12f35-be2e-4f20-45a2-08d9840cccae
X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB5600.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Sep 2021 12:21:15.9612
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 954wTYkxX9m5rOjLoyvleCp5N6DGDbZG1BjyA40SVZduq+MykI2PgMgKYRFbVzCt5vOo7bS2PLhXCApvTzY0nQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB7038
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Both xen_pvh and xen_start_flags get written just once early during
init. Using the respective annotation then allows the open-coded placing
in .data to go away.

Additionally the former, like the latter, wants exporting, or else
xen_pvh_domain() can't be used from modules.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
I have to admit that it is completely unclear to me which form of
exporting I should have used: xen_domain_type is GPL-only while
xen_start_flags is not, yet both are used in similar ways, extending to
xen_pvh. Picking the GPL version was suggested by J=C3=BCrgen.
---
v2: Use EXPORT_SYMBOL_GPL().

--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -75,7 +75,7 @@ EXPORT_SYMBOL_GPL(xen_have_vector_callba
  */
 enum xen_domain_type __ro_after_init xen_domain_type =3D XEN_NATIVE;
 EXPORT_SYMBOL_GPL(xen_domain_type);
-uint32_t xen_start_flags __section(".data") =3D 0;
+uint32_t __ro_after_init xen_start_flags;
 EXPORT_SYMBOL(xen_start_flags);
=20
 /*
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 #include <linux/acpi.h>
+#include <linux/export.h>
=20
 #include <xen/hvc-console.h>
=20
@@ -18,10 +19,11 @@
 /*
  * PVH variables.
  *
- * The variable xen_pvh needs to live in the data segment since it is used
+ * The variable xen_pvh needs to live in a data segment since it is used
  * after startup_{32|64} is invoked, which will clear the .bss segment.
  */
-bool xen_pvh __section(".data") =3D 0;
+bool __ro_after_init xen_pvh;
+EXPORT_SYMBOL_GPL(xen_pvh);
=20
 void __init xen_pvh_init(struct boot_params *boot_params)
 {