[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IOMMU page table freeing

  • To: Paul Durrant <paul@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 10 Aug 2021 15:37:43 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8BBexWQ+PyfmhndQCiT/AdDLomjgszk9QdE+e5xhB6A=; b=W+WGnw3p/vbX0984MZZvElRpHjcxV+RscJuat+3IDdnwoosIUo+fldSYwXtancoU65jIeOFI7dl/NkgcvdKKFYdoHfirWV1Gu0kpvbFzRvsqCU9SjTgYtr9ajSNLaFeTKVMoJ1b4Tf/c6SOLf8Z4Y1/FAioGyP/gewWB9bPHEDpgz9qQGZb8HX4cT1iZclGSYIlhEul8iZvU4yQCpQvmnnqqqELfXFRHvQdsoqFfe4gfv1RuGZQfPBoN8Tt9XdxBKZ5aAY6MjyT8MR0bitTnPJdidTFWuemx4pRaEBR3qLjc96gC9cSkJmVyv2VE9YK+NtWC7Nn/nzUxepOyltIpmw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KAfIhyiZxGw83fuK7ra2IIZRnjBDRX5o77fLBrMK9Nbqb2BJYXEEc+IToI6awW8bx1k6ttwjJ5y7ItN/JwmqAEFNnOsL014JHVLUAxCQgLZV5B1lO2LBlpDAeT255Sv2FJw5KtQT9YLwNd7xXbxDgw21/GSGwBlEY03sTJN7H0zTnKSnaQOxxlrRZ5l5she3N+xc9CP/CddsvzaLNupszVEU7GzzMvQ9M8AoEvQ4aUmUy2MBqaunO0grO42av5DfKnXxyVtDLTrgWae34D27fpz2shIvcln2VKtuY2GAPEuPZGp++zl31mjGpbMORCvgTsKOhgbCb0W/SPu8wgbBVQ==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 10 Aug 2021 13:38:08 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>


while I don't expect this case to occur often in practice, for
superpage support we will need to be able to correctly free a
page table (hierarchy) after replacing its mapping range by a
superpage. Following P2M by carrying out an immediate iotlb flush
prior to synchronously freeing the memory looks, to me at least,
out of question as an option - the latest when considering ATS
the flush may simply take too long.

Making use of RCU doesn't look like a good option either, as
this would require callers of map/unmap + flush to enclose the
whole group of operations in an RCU-read-locked region. Yet I
think we want to avoid to concern callers with details of the
implementation of the IOMMU operations.

Which I think leaves deferring the freeing to a softirq or
tasklet, of which the latter - to me - would seem the better
(easier) choice. If you have any alternative / better suggestions
I'd appreciate a reply; ideally you would also reply if you
simply agree.

FAOD I don't think I want to make an attempt just yet to care
about the case of flushes getting carried out asynchronously:
That would require a means to signal to the freeing function
which prior page table pages are ready to be freed. For now I'm
rather considering to merely accumulate these pages simply on a
(perhaps per-CPU) list, for the tasklet handler to consume.

Thanks, Jan



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.