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

Re: your change "iommu: make map and unmap take a page count, similar to flush"

  • To: paul@xxxxxxx
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 23 Jul 2021 08:24:33 +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=zmeApPHhlgFHu91apKk0n7x5cvV6anvVNM0ZknI1MXU=; b=YuM/VxK2dKPnwR3jPJasGcvbcvnggPCpnSMzxlMSpK3WApZbaTCatq4fYI+hDeuR5oMYs1Oquhy3I9J+s2wJN3dodP6Et1b0NANE4b3iTZyDJ2hltgjyK6Y/fP/d0vdClAiE8GYAQOFoFUQriP3DyE851ILzcO2hE3OORZdSfOXweazpe+Pwpm9sYb8zX/kvtKPfNLwpmIqdbA0Ie6oQkEjrPZcMh3R3TojtckAaK4r8SaTxHIKQADxw+QE076lVF3h34ZWwnMvMNrHVRnSfcTUg1TUwfS2v1Bzg15jjp82TOvFkjZ/WH+6wppvGUvezcZFXdTB6ejeSTqkhG4Nxtw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JOvgyH5MIvtrciEU+xVPrfTrE04V15cTDAnobGJwDsclbS/pki0vlXHHnOJVJ01kFIDFRAR9fyDbq9riAmzF8C1H65f91Ga6iNsKC/6sctbvKFJjjnG/ARQYl3Lx66ESTRV8yNGvyUlU1swr3NV7J1+zY2728/iWBLJoiUtPxIFkAnMeJNvRjVb+br4pXbj3H9fBuFU6b30x/0uYmS2cBOEIjw3sdtIRbavspNBKIOuy/FJIDJXnnOuVyI1Ke9P/5O3dEHZ9EeLlXRzB3mXjd25QQhNntTCtIIJjUnBlYHliPbWzzAWQZJWv+orpKN8PpXTEtTm8QRlUKOV8j3BHlA==
  • 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: Fri, 23 Jul 2021 06:25:04 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 21.07.2021 18:53, Paul Durrant wrote:
> On 21/07/2021 16:58, Jan Beulich wrote:
>> Paul,
>> the description of this says
>> "At the moment iommu_map() and iommu_unmap() take a page order rather than a
>>   count, whereas iommu_iotlb_flush() takes a page count rather than an order.
>>   This patch makes them consistent with each other, opting for a page count 
>> since
>>   CPU page orders are not necessarily the same as those of an IOMMU."
>> I don't understand the latter sentence at all, now that I read it again.
>> What may differ is the base page size, but that affects counts of pages
>> and page order all the same.
> What it's supposed to mean is that a CPU may e.g. have page orders 0 
> (4k) , 9 (2M), etc. but the IOMMU may not use the same orders. And by 
> page count it means a count of (CPU) order 0 pages (which I assume all 
> IOMMUs will support).

Oh, that's still somewhat odd. Which particular (higher) orders an IOMMU
variant supports should be of no interest in what the generic layer
passes down. For example in reality the AMD IOMMUs support all page
orders, by allowing "non-default page size" through a leaf level setting
of 7. I'd therefore expect the generic layer to pass down arbitrary
order values, with the vendor code needing to split the request if

The only thing that the generic layer needs to know is the base page
size, because it can't request mappings that are finer grained than
that. But perhaps for the immediate purpose we can continue to assume
a common base page size of 4k.

>> I'm intending to make an attempt to cut through the page order (or
>> count) to the actual vendor functions, in order to then be able to
>> establish large page mappings where possible. In all cases (perhaps
>> most noticable on Arm) handing them a page order would seem easier, so
>> I was considering to have iommu_{,un}map() do that step of abstraction
>> (or transformation). But since you did explicitly convert from order to
>> count, I was wondering whether me following this plan would cause
>> problems with any of your further intentions back then.
>> If we really wanted to cater for base page size varying between CPU and
>> IOMMU, besides the IOMMU vendor code needing to announce their value, I
>> guess we'd have to do quite a bit more abstracting work, as it would
>> matter to outer layers in particular if the IOMMU base page size was
>> larger than the CPU's.
> Yes, if the order 0 page size was different between IOMMU and MMU then 
> that would clearly be more tricky to deal with.
>> Supporting just smaller IOMMU base page sizes,
>> otoh, would seem entirely feasible to deal with inside the rework of
>> iommu_{,un}map() as mentioned above.
> Yes. The aim of the patch was really only to make the calls consistent. 
> Changing all of them to use an order rather than a count would be ok too 
> I think.

I'll go check whether all the flush operations would convert cleanly,
and if so I may indeed move things back and beyond.




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