[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 12/15] VT-d: replace all-contiguous page tables by superpage mappings
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Thu, 2 Jun 2022 11:35:10 +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=nG2N9ig/MGr7QL3pa8iPLcL2fzuWvxlFjObLcXccWpA=; b=K8W8rk2gLQUpxPG63Ai6g62KvnMHTKTQ21hnfiKg+b3ePNPxa+ON0q2rUgNkDoMOnqjG2ELYtvMcOFY2+0R9TwSY4UkiXbuowzGe8/ZtMsEZ9Iev/fLEpl4rRkWH2qsM0d3saWg9k5lrgzWoU5B3Z1KTuppPhlBffn77MUiji1tE8uR4ahQJwA/aDChVwUOwENjH63zEWpmjGDqReXihoefdLd7GfeGehgrflR6hhwwGeUJI2VNfEtSK5mjzZNlzQ5sc1b/1NsQzTm0yiYffh4lcrnuxg9DkfXBFRJFNOvtvVOJwMWjzNSHoo5blcVq+gQMAb2RmFknnMfzeK0dG0w==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xengb/0ZL+Dz+xsO+KKuSv1066h/AW8ae0c1bl1cw86AiAmeuM618fA5GxNVbmXVjpvMnB2R74GNgIcfngTphBqD1hRIQhx8zGV2BT8ElNEeIO5v4lNibdO5ZuSCf/drl1qU5gNPBM1qyMjHKrQ5nzFW60YeUSRbCAbhxIro0O2PU+PJzj1KcHiKkht+IBcirmsl+ZsTn59HfgDa9cMg2Wm0/3skjTfdaZ67k1S+aQvJiXftjV+cs+sMNRD+39SdSVe1UHrhlfCUdOUmDmNO6YTmOsPBusATliLOjULW7kACCLRkDfHTuJ5LzY8fJgQJKW6B0yS68sNvaQ4KbFqLxg==
- 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, 02 Jun 2022 09:35:29 +0000
- Ironport-data: A9a23:Ae3tCqooywHnTimQwDwRVioce1peBmJuZBIvgKrLsJaIsI4StFCzt garIBnQb/2JZ2ChfYt/a4nl9hsH6MCHnIJkQAU6rS01EXgXpJuZCYyVIHmrMnLJJKUvbq7GA +byyDXkBJppJpMJjk71atANlVEliefQAOCU5NfsYkidfyc9IMsaoU8lyrdRbrJA24DjWVvT4 Yqq/6UzBXf+s9JKGjNMg068gEsHUMTa4Fv0aXRnOJinFHeH/5UkJMp3yZOZdhMUcaENdgKOf M7RzanRw4/s10xF5uVJMFrMWhZirrb6ZWBig5fNMkSoqkAqSicais7XOBeAAKv+Zvrgc91Zk b1wWZKMpQgBFaLiuaMCCwNjPiRELPZs16DKGGShiJnGp6HGWyOEL/RGKmgTZNRd0MAnRGZE+ LofNSwHaQ2Fi6Su2rWnR+Jwh8Mlas72IIcYvXImxjbcZRokacmbH+OWupkFjHFp2Z0m8fX2P qL1bRJ1axvNeVtXM0o/A5Mihua4wHL4dlW0rXrK//RmvjOJlmSd1pDLMev8SPisRf5M3UK3o GWc5V3aABEjYYn3JT2ttyjEavX0tSHxVZ8WFba43uV3m1DVzWsWYDUGWF3+rfSnh0qWX9NEN 1dS6icotbI19kGgUp/6RRLQiGaNoxo0S9dWVeog52mwJrH85g+YAi0OSG5HYdl/7csuH2V1i xmOgs/jAiFpvPuNU3WB+7yIrDS0fy8IMWsFYixCRgwAizX+nLwOYtv0Zo4LOMaIYhfdQFkcH xjiQPACuogu
- Ironport-hdrordr: A9a23:Ylrhkaxj5V2snVtm/9VqKrPxvuskLtp133Aq2lEZdPULSKGlfp GV9sjziyWetN9wYh4dcB67Scy9qFfnhOZICO4qTMyftWjdyRKVxeRZgbcKrAeBJ8STzJ8/6U 4kSdkFNDSSNykEsS+Z2njeLz9I+rDunsGVbKXlvhFQpGlRGt1dBmxCe2Km+yNNNWt77c1TLu vg2iMLnUvoRV0nKuCAQlUVVenKoNPG0LrgfB49HhYirC2Dlymh5rLWGwWRmk52aUIF/Z4StU z+1yDp7KSqtP+2jjfaym/o9pxT3P/s0MFKCsCggtUcbh/slgGrToJ8XKDqhkF8nMifrHIR1P XcqRYpOMp+r1vXY2GOuBPonzLt1T4/gkWSvWOwsD/Gm4jUVTg6A81OicZyaR3C8Xctu9l6ze Ziw3+Zn4A/N2KOoA3No/zzEz16nEu9pnQv1cQJiWZEbIcYYLhN6aQC4UJuFosaFi6S0vFqLA BXNrCc2B9qSyLbU5iA1VMfg+BEH05DUytue3Jy9PB8iFNt7TJEJ0hx/r1rop5PzuN5d3B+3Z W0Dk1ZrsAxciYoV9MMOA4ge7rBNoWfe2O7DIqtSW6XZ50vCjbql6PdxokTyaWDRKEopaFC6q gpFmko/1IPRw==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Fri, May 27, 2022 at 01:19:55PM +0200, Jan Beulich wrote:
> When a page table ends up with all contiguous entries (including all
> identical attributes), it can be replaced by a superpage entry at the
> next higher level. The page table itself can then be scheduled for
> freeing.
>
> The adjustment to LEVEL_MASK is merely to avoid leaving a latent trap
> for whenever we (and obviously hardware) start supporting 512G mappings.
>
> Note that cache sync-ing is likely more strict than necessary. This is
> both to be on the safe side as well as to maintain the pattern of all
> updates of (potentially) live tables being accompanied by a flush (if so
> needed).
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> ---
> Unlike the freeing of all-empty page tables, this causes quite a bit of
> back and forth for PV domains, due to their mapping/unmapping of pages
> when they get converted to/from being page tables. It may therefore be
> worth considering to delay re-coalescing a little, to avoid doing so
> when the superpage would otherwise get split again pretty soon. But I
> think this would better be the subject of a separate change anyway.
>
> Of course this could also be helped by more "aware" kernel side
> behavior: They could avoid immediately mapping freed page tables
> writable again, in anticipation of re-using that same page for another
> page table elsewhere.
Could we provide an option to select whether to use super-pages for
IOMMU, so that PV domains could keep the previous behavior?
Thanks, Roger.
|
