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

Re: [PATCH v2 12/18] AMD/IOMMU: allow use of superpage mappings


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 13 Dec 2021 09:49:50 +0100
  • 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ohJ8t7lloX5sC8D8ws7KI7zCjKwxwysN4U15Zet3tsg=; b=XFPQE4u0aUS2fpDTk+Vfsyk48dtkdq00e/v4CH9l8FTIttxTtmEeCTkl2zmLNVPJfX+kkU3Pm2+WnlGObBXfXaX8SmW6l1l+Ys/D180YNwQfzPTrMMcw0JZT6x/+WA1iG/91SdLo9g9z/3PvizoWg0nlnMzFAbFw5kwa7+0sm4KwAZVWw+YGFhSievec8Y9HOy6tzFLnO4WWUzFgyD7sMlApkC+YbQIkpqbom8MZ9X8DwLKgpvqCOLYkZ1ZVFGsELliAIO9yKp7186x4Vm2wouyqPK4jtu2FUve8//ZMkdpbT8Hm7oENQXoAlOgJf882DNWnUzL4CFWPem3wOEhknA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Pdcf1JzdYEcnIwv9ClK2AJfo2GCnzY3FO40uE1lqreiGBZ1IRqk/0AN3mN4+Yj6S/QDUdOhLcETqqsf+tlwPMotTDHR6j915Jx58IxBLB9xybCQveTGnotRzViFa1SJyaC4xTl2PWkcIF40a9aKjW/ixQJFmLdg2OT62OoxMgti0NOwkpfJijxUtYCRXSj4DybdRt7FshlAJLguBrlEHQTxZWdN6DVSVt+IPg5FPX7gBpak9ySfBw9JER2GVDQREpsZbWQi3HzLsNHPG/P7UMCQ8veuojf8cjw2lNBmeSaGNMQ3bEfwlwQ1ohdIaGPrd2YWWhfkILpNj220CJjq9xQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Paul Durrant <paul@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Mon, 13 Dec 2021 08:50:00 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 10.12.2021 16:06, Roger Pau Monné wrote:
> On Fri, Sep 24, 2021 at 11:52:14AM +0200, Jan Beulich wrote:
>> ---
>> I'm not fully sure about allowing 512G mappings: The scheduling-for-
>> freeing of intermediate page tables can take quite a while when
>> replacing a tree of 4k mappings by a single 512G one. Plus (or otoh)
>> there's no present code path via which 512G chunks of memory could be
>> allocated (and hence mapped) anyway.
> 
> I would limit to 1G, which is what we support for CPU page tables
> also.

I'm not sure I buy comparing with CPU side support when not sharing
page tables. Not the least with PV in mind.

>> @@ -288,10 +289,31 @@ static int iommu_pde_from_dfn(struct dom
>>      return 0;
>>  }
>>  
>> +static void queue_free_pt(struct domain *d, mfn_t mfn, unsigned int 
>> next_level)
> 
> Nit: should the last parameter be named level rather than next_level?
> AFAICT it's the level of the mfn parameter.

Yeah, might make sense.

> Should we also assert that level (or next_level) is always != 0 for
> extra safety?

As said elsewhere - if this wasn't a static helper, I'd agree. But all
call sites have respective conditionals around the call. If anything
I'd move those checks into the function (but only if you think that
would improve things, as to me having them at the call sites is more
logical).

Jan




 


Rackspace

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