[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 10/21] AMD/IOMMU: allow use of superpage mappings
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Thu, 5 May 2022 17:26:00 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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=H/sS0UFMyGyYLTYuRV9TlNc2+7wqOivnI478LpcvgCI=; b=Jjezb63VkcG1k+0notYwCOcqfjGFLvkF0iCogjGOeToIb33ZNL+SNgsiJJlYHCJPmgG9yces2UrSYY2WsvoXYEP8euuBUgqIj5UbJ6B6nBTm3YkKPHyJXzd0iop/7Vic4jnAYcDQ2Zb/h/ootyH4pLSzqDFg/sYW+L1swcdP+4id9wCl95jRhSEgSmI/Bd7qRKzPjPzo1rP4SWyW9Lws9hPxqgnYlPwv+oAX1OQFKyB661Qft120MWZ5CZ7mWnL9ezR/WQAJoUxcgtsdoJAzQEDIlZmBAJGZSZ0up8pV1Cbps6OTiimyESsa+xTDfi678WAYqqZ70xv2GkMjtYF58Q==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k29rgCUmlLcziN/ewwMQLsCuGfTiR7p0U1px1U+j3xFjCByOZzDXEtsX5n0gfjGO/Md7fQVJwGeL2N2wkPadGuIwLeVMdAlHp2xafJvffMmhsAKZhjuwXkKBUAB4kaPhEPXWIu0Hq4P+jt5yZPhvHwB9ql+ZDii0Ur7GDzJxQs3b1mu/c8kGoqovfcnpx/wMvHFL06JPyLi+VZ8kzHnX5RqKbozAwgXmwVmrL3Dfg+t2aXXFOOQi4rhu5YZAqDjZKyK6oev/jiIXyeNk7dTKhzLcRCsBujjgjP9+ju2GmTihoL4Tb83PSQ38Nlrpk6k1+wLcj0+vCl7PT/xjVkkrog==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Paul Durrant <paul@xxxxxxx>
- Delivery-date: Thu, 05 May 2022 15:26:24 +0000
- Ironport-data: A9a23:b4PMSq3rEALhnSCe4vbD5aRwkn2cJEfYwER7XKvMYLTBsI5bpzFUn zQcDTuEaa6CNzTxf91yOYjk90IPsJTUm4VjSFQ5pC1hF35El5HIVI+TRqvS04J+DSFhoGZPt Zh2hgzodZhsJpPkjk7xdOCn9xGQ7InQLlbGILes1htZGEk1EU/NtTo5w7Rj2tMw3IDja++wk YiaT/P3aQfNNwFcagr424rbwP+4lK2v0N+wlgVWicFj5DcypVFMZH4sDfjZw0/DaptVBoaHq 9Prl9lVyI97EyAFUbtJmp6jGqEDryW70QKm0hK6UID66vROS7BbPg/W+5PwZG8O4whlkeydx /1Tlce6QBdyDJfKhbpEUzN6HxhDEvRJreqvzXiX6aR/zmXgWl60mbBEKhhzOocVvOFqHWtJ6 PoUbigXaQyOjP63x7T9TfRwgsMkL4/gO4Z3VnNIlGmFS6p5B82aBfmTjTNb9G5YasRmB/HRa tBfcTNyRB/BfwdOKhEcD5dWcOKA2SKmL2AH9Az9SawfoFTLwkt6/rjRL9/WcYeGecYEmQWYn zeTl4j+KlRAXDCF8hKH+H+xgu7EnQvgRZkfUra/85ZCkFCVg2AeFhASfV+6uuWizF6zXcpFL E4Z8TZoqrI9nGSzR8T5dw21pjiDpBF0ZjZLO+gz6QXIwKyN5Q+cXjcAVmQZNIVgs9IqTzs30 FPPh8nuGTFkrLySTzSa66uQqjSxfyMSKAfueBM5cOfM2PG7yKlbs/4FZowL/HKd5jEtJQzN/ g==
- Ironport-hdrordr: A9a23:oHUoZKmEuGQLIE5EO1O5VCZg1afpDfO+imdD5ihNYBxZY6Wkfp +V8cjzhCWftN9OYhodcLC7V5Voj0mskKKdxbNhRYtKOzOWw1dATbsSlLcKpgeNJ8SQzI5gPM tbAstD4ZjLfCJHZKXBkXaF+rQbsb66GcmT7I+xrkuFDzsaDZ2Ihz0JdjpzeXcGIDWua6BJdq Z1saF81kedkDksH42GL0hAe9KGi8zAlZrgbxJDLxk76DOWhTftzLLhCRCX0joXTjsKmN4ZgC P4uj28wp/mn+Cwyxfa2WOWx5NKmOH5wt8GIMCXkMAaJhjllw7tToV8XL+puiwzvYiUmR4Xue iJhy1lE9V46nvXcG3wiRzx2zP42DJr0HPmwU/wuwqWneXJABYBT+ZRj4NQdRXUr2A6ustn7a 5N12WF87JKEBLphk3Glpf1fiAvsnDxjWspkOYVgXAae5AZcqVtoYsW+14QOIscHRj99JssHI BVfY3hDc5tABKnhk3izylSKITGZAVxIv7GeDlOhiWt6UkZoJgjpHFohvD2nR87hecAotd/lq H5259T5cBzp/8tHNxA7dg6MLuK40z2MGXx2TGpUCLa/J9uAQO/l7fHpJMI2cqNRLskiLMPpb WpaiIriYd1QTOlNfGz
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Thu, May 05, 2022 at 04:34:54PM +0200, Jan Beulich wrote:
> On 05.05.2022 15:19, Roger Pau Monné wrote:
> > On Mon, Apr 25, 2022 at 10:38:06AM +0200, Jan Beulich wrote:
> >> No separate feature flags exist which would control availability of
> >> these; the only restriction is HATS (establishing the maximum number of
> >> page table levels in general), and even that has a lower bound of 4.
> >> Thus we can unconditionally announce 2M, 1G, and 512G mappings. (Via
> >> non-default page sizes the implementation in principle permits arbitrary
> >> size mappings, but these require multiple identical leaf PTEs to be
> >> written, which isn't all that different from having to write multiple
> >> consecutive PTEs with increasing frame numbers. IMO that's therefore
> >> beneficial only on hardware where suitable TLBs exist; I'm unaware of
> >> such hardware.)
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> >
> > Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>
> Thanks.
>
> >> ---
> >> I'm not fully sure about allowing 512G mappings: The scheduling-for-
> >> freeing of intermediate page tables would take quite a while when
> >> replacing a tree of 4k mappings by a single 512G one. Yet then again
> >> there's no present code path via which 512G chunks of memory could be
> >> allocated (and hence mapped) anyway, so this would only benefit huge
> >> systems where 512 1G mappings could be re-coalesced (once suitable code
> >> is in place) into a single L4 entry. And re-coalescing wouldn't result
> >> in scheduling-for-freeing of full trees of lower level pagetables.
> >
> > I would think part of this should go into the commit message, as to
> > why enabling 512G superpages is fine.
>
> Together with what you say at the bottom I wonder whether, rather than
> moving this into the description in a slightly edited form, I shouldn't
> drop the PAGE_SIZE_512G there. I don't think that would invalidate your
> R-b.
Right, might be good to add a comment that 512G super pages could be
enabled (ie: there's no hardware limitation), but we need to be sure
that the freeing of the removed page table pages doesn't starve the
pCPU.
Thanks, Roger.
|
