Received-SPF: pass (google.com: domain of linux-kernel+bounces-98108-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
From: Ankit Agrawal <ankita@nvidia.com>
To: Catalin Marinas <catalin.marinas@arm.com>, Jason Gunthorpe
	<jgg@nvidia.com>
CC: "maz@kernel.org" <maz@kernel.org>, "oliver.upton@linux.dev"
	<oliver.upton@linux.dev>, "will@kernel.org" <will@kernel.org>, Aniket Agashe
	<aniketa@nvidia.com>, Neo Jia <cjia@nvidia.com>, Kirti Wankhede
	<kwankhede@nvidia.com>, "Tarun Gupta (SW-GPU)" <targupta@nvidia.com>, Vikram
 Sethi <vsethi@nvidia.com>, Andy Currid <acurrid@nvidia.com>, Alistair Popple
	<apopple@nvidia.com>, John Hubbard <jhubbard@nvidia.com>, Dan Williams
	<danw@nvidia.com>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>, "kvmarm@lists.linux.dev"
	<kvmarm@lists.linux.dev>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 1/2] KVM: arm64: determine memory type from VMA
Thread-Topic: [PATCH v1 1/2] KVM: arm64: determine memory type from VMA
Thread-Index:
 AQHZ4bc9eKM9qzFPEkOCPCVLZRI57LA7iuuAgAAK/gCAB7HcAIAACxYAgAAlfgCAABHzAIABh9MAgAAOv4CAAWqOgIDq6ccH
Date: Sun, 10 Mar 2024 03:49:36 +0000
Message-ID:
 <SA1PR12MB7199AB860E0C76B80B421C66B0252@SA1PR12MB7199.namprd12.prod.outlook.com>
References: <20230907181459.18145-1-ankita@nvidia.com>
 <20230907181459.18145-2-ankita@nvidia.com> <ZR7hKYU1Wj+VTqpO@arm.com>
 <20231005165458.GM682044@nvidia.com> <ZSVe0nb02S4kz5D2@arm.com>
 <20231010150502.GM3952@nvidia.com> <ZSWHkvhutlnvVLUZ@arm.com>
 <20231010182328.GS3952@nvidia.com> <ZSbfUNLwDkaYL4ts@arm.com>
 <20231011183839.GC3952@nvidia.com> <ZSgb0WBSsXHHYJT0@arm.com>
In-Reply-To: <ZSgb0WBSsXHHYJT0@arm.com>
Accept-Language: en-US
Content-Language: en-US
msip_labels:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=nvidia.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SA1PR12MB7199:EE_|DS7PR12MB5982:EE_
x-ms-office365-filtering-correlation-id: 7d57bfed-2025-4fb6-a2ef-08dc40b51aa9
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 +ubToWL19CsqHFN0n+zypFWNCddIli2QgkVRmqClCmMawhPeYvvih8AAInhZcxKV2ik2Jg5IMvMLB15A1Dr5RjhNgGEuMhDjUXMGCi8oYSk7h0yN4+JbQbYH0XjRTjidW7xrklQYzkCgpH0HrlAeS0vDhgzQdo168/t42PtGHHR7sIjiygoQAEHJDK1vb4iSJwe7v97shWIRsL+RwlhijtBvO6EoLzEvGwLIOAA5KyhJs6xPBVUrZ3jn3dS7KBE6VKz260LRQCId2PI1qOXwe+ocxuXMD1mCK7htpJv1S+cycCt/rO6Xvr/PNj5F9jTVQoSdFOP76uJlsRUi86PJWodOglnYiqGRDra38+lDVV4pLO7vVQHEwf5qP8qyAd+t6HVmx+ACwFQv6y+yfHYEn62Y3ufiol/glXcobPk99bivbSxybnwWeKoLSyFGXifcIboCocibLHW9/r0sf+tunREtCEZgem/8DN0KZeKIrGIjY1cFdSoGCriYXd8MH2b/7Cyoclzl/+S3bCK0vBLb+ihzFxvDHuUQuVaV1xhZQosod1wspEiWxZI2Y2Ly98DtNZe+wFeksUxzzPeWKAEN7WbhR8hmt04oFtm4gQi/4cAAIuQuaUYr4AG47UX0YDAe1B9PDkR5cVMt6/kGPxUNVtWxMuss3RutRx9r5vVmamPPaKdgbBDoxo8y+knXb4ImmhBvuniTjxv1W/E4B7ig0eCMUqNYbfaP0eUYdpVe9B4=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA1PR12MB7199.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(1800799015)(376005)(38070700009);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?qFlkR63l09EL99uoPXRGplmeJlKgyIao0Tne2+telPjdULuzbNOpAxqqR7?=
 =?iso-8859-1?Q?TMxxSZIvwX9tGoi1nA1VziRBEBRaHFkNX5x4kQKgDAfstdyYd1W74Nl8WU?=
 =?iso-8859-1?Q?vTOdCUTi5NRIneaTqV5RTKXBvQtNww2/7K9OllpOF6BKCCrcVEq46Ssg9p?=
 =?iso-8859-1?Q?cgUUxrD1f+rDyvPVid/AJd8MH9zXyutWeaxPJirflowbJnx/e4MFO/s817?=
 =?iso-8859-1?Q?gCtnd4XgVvn69G4l8lkTKgz25lKx5WSkS9Zr7pBbtLAC/1H0lbwipUQveB?=
 =?iso-8859-1?Q?0cQffXGuUGUxGa2jrnfTKtDEHh9yztD4a06/90/kwd864FPP6uZoQkYUST?=
 =?iso-8859-1?Q?83mxCyCHnkD1QFSvPJfwsyP3wUFY6MzVuOita3ax4brOQJObKd5FjV273O?=
 =?iso-8859-1?Q?RO/Qp3jQPhIlbE00+3AHIjqxLnGdaoFC6A4DayBYuD2YKCKnHYVSL75Ens?=
 =?iso-8859-1?Q?7HSIcm+OlDQuha1bHjTJsW2RBvqVf2J4EVmSlhPltVR+LYdl8Vsi4n1FvA?=
 =?iso-8859-1?Q?MDy/AcYrmim7kT332bYLklHD9f3cHld2Vs6fABnwHtQ0CxIapVI3ZoZHda?=
 =?iso-8859-1?Q?M0Huicru9PNk35IqhQ0z4QYC4tzXO2tZgwqch86fbNxLnzFKqdFIMzHL7J?=
 =?iso-8859-1?Q?mWG+eHdQM7pVZfcCyvxpuvhvs4bpNk8tCcH0moWbZglLehuVXv8XCpxe4U?=
 =?iso-8859-1?Q?+varg+cqz1cJYAfXx9QxZGWorvbb6rwIqC3HM5r8nZkLg7v9YJbg5t+KSw?=
 =?iso-8859-1?Q?HI5wI/Q6dd3+tmggmuSLXj7Ncxz6TUdavTqcqJvnO8wRRrZ5SljiplJUU5?=
 =?iso-8859-1?Q?Y0AlqPID+/hLy7hRHzDNosXMYsRQohY0sRQoducjtrntMc9nrvT3+uACFg?=
 =?iso-8859-1?Q?kSWvu7L8XGi0AyqQB8UEqUBiv2ZwVowe5TY7iag4zrWTf7zWXdDnjFHjjj?=
 =?iso-8859-1?Q?b2NJRFSMpmaqDqK73dlh1qEhMO7d1wsBq7x5BQ1t+mphXJV5BWG+1EUt/Q?=
 =?iso-8859-1?Q?CPZNVPMFOMOkaz7qhMDtbR87Asy1y5v3uv7OH0huXoivoQc81xDEgs+q+2?=
 =?iso-8859-1?Q?dZ6MPeewKqH2CETvuLPwZT4o7SrLuDHIMnIl9KXp6dYJpXVjnl5OGv6EZp?=
 =?iso-8859-1?Q?+cjrCjEjIFDUgX3WKjwCvsraNs4sVe0KGlhOCOfRfqzoWxxOR36RN9dFd9?=
 =?iso-8859-1?Q?MKvkDfcjFlvI5PzMY/nMWYzk9/iyr5KxebOcVz1P1u1PcpsHCxJ9NMhBum?=
 =?iso-8859-1?Q?96X+evAvCj1jLYvPzd+7InhhOxEP6c0GTZuwntP8CpdjV7zAymApWeAtAg?=
 =?iso-8859-1?Q?XEp6Hyhhz43KajVT+gpYc4eJzSOocz5ghWn4GzcB3EOrrc0tz9i8rZJaVO?=
 =?iso-8859-1?Q?bKNunzmDGV8miwJ5iqK0CloTwfTsf0TK5BCLnop/jL5SHwd23FgMh0cLBl?=
 =?iso-8859-1?Q?mMFRz49gPC7HfKPPKXk3zeSgVMVOc+//RiU+nhes03MZStlu6W3R+PD63F?=
 =?iso-8859-1?Q?QICpvrsY6Q2gL5Brt0i232MtW7ckuivzjTVKYNO4b10QuUsQ1uw9+2fwiP?=
 =?iso-8859-1?Q?jYMbmtnJYxBAWzo58jq43LQSG+W8vmKQeEu9bhpbdGl5C2ZsRmB1463UI6?=
 =?iso-8859-1?Q?1ulU1AP/DR4Yo=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA1PR12MB7199.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7d57bfed-2025-4fb6-a2ef-08dc40b51aa9
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2024 03:49:36.0203
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: wlnD2xZpAkmqkCZQhqtMSizfsDVjYW9KhgCHXgE20XNqryjgsyMvO1lOZ8owkZDsDmFZ7yxP034DsS7twPhVgw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB5982

Bringing this to the fore.=0A=
=0A=
>> Where does that leave us for this patch? We check the VM_MTE_ALLOWED=0A=
>> and check for ZONE_MOVABLE struct pages as one of the conditions for=0A=
>> NORMAL?=0A=
>=0A=
> I think we should keep it as simple as possible and, looking at it=0A=
> again, maybe even ignore vm_page_prot. Two questions though:=0A=
>=0A=
> 1. Does VM_IO imply vm_page_prot never having MT_NORMAL or=0A=
> =A0=A0 MT_NORMAL_TAGGED?=0A=
>=0A=
> 2. Do all I/O ranges (side-effects, non-RAM) mapped into a guest (and=0A=
>=A0=A0 which end up in user_mem_abort()) imply VM_IO?=0A=
>=0A=
> If yes to both, I think something like below would do:=0A=
=0A=
How may we get the answer to these? It seems to be the logical behavior, bu=
t=0A=
how can we confirm?=0A=
=0A=
While we discuss on that, I am considering to send out the next version of =
this=0A=
patch (incorporating the feedbacks on the thread) that is rebased to a comm=
it=0A=
inclusive of the recently applied KVM patch series:=0A=
=0A=
[KVM: arm64: Allow the VM to select DEVICE_* and NORMAL_NC for IO memory]=
=0A=
https://lore.kernel.org/all/20240224150546.368-1-ankita@nvidia.com/=0A=
=0A=
>=A0=A0=A0=A0=A0=A0=A0 mte_allowed =3D kvm_vma_mte_allowed(vma);=0A=
>=A0=A0=A0=A0=A0=A0=A0 noncacheable =3D false;=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 // or 'device' as in us=
er_mem_abort()=0A=
>=A0=A0=A0=A0=A0=A0=A0 ...=0A=
>=A0=A0=A0=A0=A0=A0=A0 if (vma->flags & VM_IO)=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 // replaces !pfn_is_map_memor=
y()=0A=
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 noncacheable =3D true;=0A=
>=A0=A0=A0=A0=A0=A0=A0 else if (!mte_allowed && kvm_has_mte())=0A=
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 noncaheable =3D true;=0A=
>=A0=A0=A0=A0=A0=A0=A0 ...=0A=
>=A0=A0=A0=A0=A0=A0=A0 if (noncacheable)=0A=
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 prot |=3D KVM_PGTABLE_PROT_D=
EVICE;=A0=A0=A0=A0=A0=A0=A0 // or the new KVM_PGTABLE_PROT_NC=0A=
>=0A=
> mte_allowed would cover DAX mappings (and, who knows, some future DAX=0A=
> mapping may allow MTE and the driver explicitly set the flag). Anything=
=0A=
> else hot-plugged into ZONE_MOVABLE should have VM_MTE_ALLOWED set or=0A=
> MTE disabled altogether.=0A=
=0A=
--=0A=
Catalin=