Received-SPF: pass (google.com: domain of linux-kernel+bounces-14641-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Tue, 2 Jan 2024 13:09:08 -0400
From: Jason Gunthorpe <jgg@nvidia.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Oliver Upton <oliver.upton@linux.dev>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>, ankita@nvidia.com,
	maz@kernel.org, suzuki.poulose@arm.com, yuzenghui@huawei.com,
	will@kernel.org, alex.williamson@redhat.com, kevin.tian@intel.com,
	yi.l.liu@intel.com, ardb@kernel.org, akpm@linux-foundation.org,
	gshan@redhat.com, linux-mm@kvack.org, aniketa@nvidia.com,
	cjia@nvidia.com, kwankhede@nvidia.com, targupta@nvidia.com,
	vsethi@nvidia.com, acurrid@nvidia.com, apopple@nvidia.com,
	jhubbard@nvidia.com, danw@nvidia.com, mochs@nvidia.com,
	kvmarm@lists.linux.dev, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	james.morse@arm.com
Subject: Re: [PATCH v3 2/2] kvm: arm64: set io memory s2 pte as normalnc for
 vfio pci devices
Message-ID: <20240102170908.GG50406@nvidia.com>
References: <20231208164709.23101-1-ankita@nvidia.com>
 <20231208164709.23101-3-ankita@nvidia.com>
 <ZXicemDzXm8NShs1@arm.com>
 <20231212181156.GO3014157@nvidia.com>
 <ZXoOieQN7rBiLL4A@linux.dev>
 <ZXsjv+svp44YjMmh@lpieralisi>
 <ZXszoQ48pZ7FnQNV@linux.dev>
 <ZYQ7VjApH1v1QwTW@arm.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZYQ7VjApH1v1QwTW@arm.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?TtBvKvohDDZNz0Vwtl3KxYxOSkw+Q7ZOm8HRc/PzlAqkgVkFMwjQE/VJ7tGz?=
 =?us-ascii?Q?QswMtmjNq1ai1rCMsTqQV03MkXqAcwMUMVRNijruYEDOYEm0pfD4YJLXUqxk?=
 =?us-ascii?Q?5KH/59vwRfvdDzM3gMU7BEG/vsAfDgX/RxhfFXa/wshGO1jqwmQnWoTVm3nl?=
 =?us-ascii?Q?QV0XAv4R9UMYdAtaaeCmKJXR9HC31bjEDKMttvezIoojYkqbqd4uQytbXJL0?=
 =?us-ascii?Q?sUVhkT+Lq4OLwsIRcrcsCc5Whjwk/RiFZ9doEXVj4jwdicAP8wEcEc6/Mfli?=
 =?us-ascii?Q?DH9qcinereDOiBuuN3FUJQ2izCO1PQQkFRvN4JmY6zFUvE61oKHdDpxfyPGx?=
 =?us-ascii?Q?4Rl76lKdcPfbsq9a9Pf0D3FrqW2gj9v81CJx608bEcRvxde70Sv5Y6s6Uaod?=
 =?us-ascii?Q?9JbjRTczBuppdYpbiCuROTsp7Bdwco5HLRFKdTReFsxzCnNGsJaSFx5SyMYy?=
 =?us-ascii?Q?bRSnW4+Uw5xWEnmB2cEn+DOiO0VyRWAzJ9EFpZLVFwPumGaABeh3ISVMnlUO?=
 =?us-ascii?Q?aIfFkIdYQcKwuss354ehL9ASulYX1EQXbWjE3VN15vw1nXXY30ApGDbWzk54?=
 =?us-ascii?Q?LuAH0GQVjtWiKhFm+ydBSwfI7g+L65TCUUYCCxWDfISJUnsrbn+tFTKamUvA?=
 =?us-ascii?Q?rJry/juZ1bwrGAIAsFWkNYEinPB/eXsRZxp2iYlFMu4c/vlA9kARSiRKt9jC?=
 =?us-ascii?Q?OAtGnUhGDlnhlFtEZ1k8oY4ltnaaHmaGVMMBQAoDec1S5MFK9JbdEp07jbLI?=
 =?us-ascii?Q?TqY8D/TslL+/16yKYFiwevK4hhR7my4uU7f7+L51Bx1gWdMTvTsakCseKIdG?=
 =?us-ascii?Q?8RJuIPnrI1GKp+NPN4aUsyLtISRtZKOLe84tMpPUFdsgrKXUdVkoRpfUZT7P?=
 =?us-ascii?Q?LNBwxFVX6dukyoUI1PPlJXo7rBK+YS9GftE8m5FS2SviC4BMVRkM6qFMyT7T?=
 =?us-ascii?Q?kO6f+d5vVJKgqcNsgosRHB/KK6ln/VdcH2epqAmurFiTMWBri32JieNhO9rB?=
 =?us-ascii?Q?JU2E+upnRt6lhfcQLeu1FvS91GzE+LAIXaTWbSHQHreaSpj8MEHq6gDiK4Ow?=
 =?us-ascii?Q?3Zn4u4uHuE6tyrSS/0D7ymOG1aaxxqv2BF7kHLq4I7nfdKuM//9JB0cjBNnV?=
 =?us-ascii?Q?5Z58BUdijP3freysxvrg0vgGRimwuXEEu6PPyNqFX2DFDzYLLut3bM9IIxgZ?=
 =?us-ascii?Q?iHnMCEGnG0J19gnrMDfEwyINAOlaNmrwgqoVLIyA0Tzjdrz9VO0WFWshwbcT?=
 =?us-ascii?Q?wTgk8xMzolSCmJNCHRZZYR8g4Dbah1xnouHYDPXet9Npcu+qnGcHpm68DTid?=
 =?us-ascii?Q?p3n44A9IZBCdjEtTOrrZErK3Bww0+5GsltXAPlIJSYXTb0ZABCiNiOT2ukJQ?=
 =?us-ascii?Q?zolN07osXhZoG2Ux6k+7z9BudPK/eicTEVHuDSOqxgS3oI1Zh1I7wnGLKpK7?=
 =?us-ascii?Q?DXEZ8sSY7Cj24m2+HpRm09/6qlzJccQ6gATd3yRMF81nnh/akbefrjN9j8Gv?=
 =?us-ascii?Q?XHe2UGh7JJ+jMr9omcs+tI0EOWMwQGjKIjm6TvgP0LAgYE2GYt+2HcHuTKmg?=
 =?us-ascii?Q?VPJihSB3WihC3MmR9zU=3D?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6de4bb8a-1139-4cd6-a05a-08dc0bb588d3
X-MS-Exchange-CrossTenant-AuthSource: LV2PR12MB5869.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jan 2024 17:09:09.4941
 (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: jORWB1Olaraj4ndpLWDuiT3ZQC+XSvFD92Wa/Ta9VO5aFzBs4zR4GIk+9i7oTwzq
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4512

On Thu, Dec 21, 2023 at 01:19:18PM +0000, Catalin Marinas wrote:

> If we really want to avoid any aliases (though I think we are spending
> too many cycles on something that's not a real issue), the only way is
> to have fd-based mappings in KVM so that there's no VMM alias. After
> that we need to choose between (2) and (3) since the VMM may no longer
> be able to probe the device and figure out which ranges need what
> attributes.

If we use a FD then KVM will be invoking some API on the FD to get the
physical memory addreses and we can have that API also return
information on the allowed memory types.

> > Kinda stinks to make the VMM aware of the device, but IMO it is a
> > fundamental limitation of the way we back memslots right now.
> 
> As I mentioned above, the limitation may be more complex if the
> intra-BAR attributes are not something readily available in the device
> documentation. Maybe Jason or Ankit can shed some light here: are those
> intra-BAR ranges configurable by the (guest) driver or they are already
> pre-configured by firmware and the driver only needs to probe them?

Configured by the guest on the fly, on a page by page basis.

There is no way for the VMM to pre-predict what memory type the VM
will need. The VM must be in control of this.

Jason