Xen project Mailing List

Re: [PATCH v2 4/6] arm/mpu: Destroy an existing entry in Xen MPU memory mapping table

To: "Orzel, Michal" <michal.orzel@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>

From: Hari Limaye <Hari.Limaye@xxxxxxx>

Date: Fri, 11 Jul 2025 06:04:25 +0000

Accept-language: en-US

Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=amd.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])

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=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=oHqF4E74Z3XVbu/u6ww4c/C+EiWf0VcecjJHUFhYwDo=; b=GiOzdY8XJAkBlverzhYbtk671Nu2ih9pIO+reEyZBkQNVMdv4GdYE6XJRTLgBcrE22+oMFMHKN63gY7YefzfRPcFHFntwbb3XFmsRWBrpWxlAVF8534tO3UgkBsvhcNP3b6Qr/gWEjUO3Du5LxB05veFQ+aXtiG578Q3y8LJHlnfJI7AyTlOYd3IgF6KnmNcUdBcUb32dk5QeI8gpZghn4e1ae6gWERjJoU8L8owlhwCOF/dO19HRrpDFwNzEIrpl0KeHjtnnHE4cbfj5OLaWFhg5HU1ZGRlauLiejxrabgfRK0C3u+77m/ZqvbNa1SuWMk4I6DZqtUaQghhUgMY7g==

Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=oHqF4E74Z3XVbu/u6ww4c/C+EiWf0VcecjJHUFhYwDo=; b=oQj5FhpRrF4puQLLrILyYpB6GwytZZ40uwSxEwcTIJ58Wr49S0DZVZmu1k0uCl4oS1HbPWFOk8fP96jVVoOa67ufrGtDXG9n9PjvQDvffTr4xYqjO3KsXuhD22QTFxI61rJOUFAeOL/S+HXEyPy1hBcpdMhMLpTvLR+ryXoTGp7opndfxQPwg7ntLHSn+JnQ/DVGNFW5GquohVDJHT9aZ5qmNdXks6UIoTxb3V/MI1zqBY2nhZ8glLFogcqXO9dd/JkVUz5GvLsQuw4dXzmV4zwEWhBH4lCDxQMZxxIAvhZ8lumiMCwu+D9AEBqf9TafGBYAPDN4xQ6l5PCbUOrklA==

Arc-seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=Z404LLJKFjtOgiWFtswhRMxrZcwCgr/jVM60qFlklhUEq8OCEsFReCBrKQS+MRWei+AtwUIJpZX2/a967EOEp6TuKE49xJsiPKf1ey7iLD9eejzgjxEdNOlZHSgBM2i2cVxfWQJ4pR9Nf7CtqFjqsCEXitA4pfYFIiXVHkPeje5BALOvjpd9t0ykiOfokTHdIgxtMrc/SQNK7MRV6GNuAF0BqAG8T/IPMniIMyFupIYmzanfTu1WcBw3GPsoXMQh+Q1VOkUNUjisUmr6ySrJw/5yfA7zAWrCUDQwMYkk0lKvOamKXkWJgCIVn2WR1SbqK9/uve/5foFVJjDknEX/KA==

Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=cUYoLO3VBLw5v0IoHQS9cZwC0EvXrJFjYxOP6LjseNCmf1gS4djocDnr4hkhjsfcgd3jvp5YVYlDf4cq9DjKFSoiWeQenGpyr8jNlGSd6RXnVmQvAE59/XTtt7YKKeJ9RCpwQAb/E+z0ajbCNoYM+DXFSTIyz3ySOFwsXUwEiskYSsQKSKQqNa7RvEi0Xh+A3EUapiWKFWXebaRZ0oboVP607dgI/PQMUMMaBhO/jzTKV3FT3m552h9WI9f6J64cdySDmrmLS4EsBwpnPeEa+GDCOMMCqnp8fTkRCnCza0ngTlbtcvYxlWmwokzTF7JYEuef7b2lKNk0COuXrKdATg==

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

Cc: Luca Fancellu <Luca.Fancellu@xxxxxxx>, Penny Zheng <Penny.Zheng@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Wei Chen <Wei.Chen@xxxxxxx>

Delivery-date: Fri, 11 Jul 2025 06:05:11 +0000

List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Nodisclaimer: true

Thread-index: AQHb8KgBNlCBCRibX0umgPaurd2jQrQscMs3

Thread-topic: [PATCH v2 4/6] arm/mpu: Destroy an existing entry in Xen MPU memory mapping table

Hi Michal,

Thank you for reviewing the patch.

> > + /* Zeroing the region will also zero the region enable */

> > + memset(&xen_mpumap[index], 0, sizeof(pr_t));

> Is it ok that for a fast case (i.e. 0-31) our representation of prbar/prlar will

> be different from the HW i.e. xen_mpumap[index] is 0 vs only .en bit of prlar

> being 0 in HW?

I think this should not matter - there is nothing reading registers directly and

all the decisions are taken looking into xen_mpumap.

However, if you would prefer, we could alter the logic here to only clear the .en

bit in xen_mpumap[index] in the fast case, so that things remain consistent? Alternatively we could always directly zero the entirety of the registers, but then we would remove the use of the fast case entirely.

Many thanks,

Hari