From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <jbeulich@suse.com>, Teddy Astie <teddy.astie@vates.tech>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Roger Pau Monné" <roger@xenproject.org>,
xen-devel@lists.xenproject.org,
"George Dunlap" <gwd@xenproject.org>
Subject: Re: [PATCH 5/5] vtd: Move intremap table to xenheap
Date: Wed, 5 Aug 2026 11:06:45 +0100 [thread overview]
Message-ID: <59d0de8f-2d97-4f65-af16-876be20398fa@citrix.com> (raw)
In-Reply-To: <451978a5-7dfd-4b91-a241-eb13caf6d394@suse.com>
On 05/08/2026 10:44 am, Jan Beulich wrote:
> On 29.07.2026 11:59, Teddy Astie wrote:
>> Interrupt remapping entries often needs to be accessed, and we're creating
>> pointers to it on demand, which brings a lot of complexity (e.g
>> GET_IREMAP_ENTRY() macro), move it to xenheap such that it's persistently
>> mapped and we won't have to worry about mapping and unmapping individual
>> intremap table pages.
> Afaic: No movement from domheap to xenheap except for _very_ good reasons.
> For the case here that is - maybe establish a permanent mapping using
> vmap(), but no change in where the memory is to come from. Whether such a
> permanent mapping is really worthwhile may also want supporting by numbers.
> You say "often", but you don't qualify / quantify this any further.
To expand on the "why" a bit more.
For systems with all RAM below the 4T boundary, domheap and xenheap are
equivalent. We have 5T of directmap, but xenheap allocations have a
width restriction which is a power-of-2.
For systems with any RAM above the 4T boundary, you can't have xenheap
allocations be NUMA-local for all NUMA nodes.
As for "often", the IRTEs are modified every time a vCPU moves to a
different PCPU, because the target addresses need updating. While it
probably doesn't matter much today, in the context of ASI it's something
which would want mapping permanently, rather than on-demand.
~Andrew
next prev parent reply other threads:[~2026-08-05 10:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 9:59 [PATCH 0/5] Misc VT-d changes Teddy Astie
2026-07-29 9:59 ` [PATCH 2/5] vtd: Ensure context entry is cleared properly Teddy Astie
2026-08-04 16:04 ` Jan Beulich
2026-07-29 9:59 ` [PATCH 3/5] vtd: Print originating iommu on faults Teddy Astie
2026-08-05 9:31 ` Jan Beulich
2026-07-29 9:59 ` [PATCH 4/5] vtd: Don't disable hwdom passthrough on unhandled SAGAW bits Teddy Astie
2026-08-05 9:41 ` Jan Beulich
2026-07-29 9:59 ` [PATCH 5/5] vtd: Move intremap table to xenheap Teddy Astie
2026-08-05 9:44 ` Jan Beulich
2026-08-05 10:06 ` Andrew Cooper [this message]
2026-08-05 12:42 ` Teddy Astie
2026-07-29 10:05 ` [RESEND PATCH 1/5] vtd: Ensure root entry is updated consistently Teddy Astie
2026-08-04 15:58 ` Jan Beulich
2026-08-05 13:03 ` Teddy Astie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=59d0de8f-2d97-4f65-af16-876be20398fa@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=gwd@xenproject.org \
--cc=jbeulich@suse.com \
--cc=roger@xenproject.org \
--cc=teddy.astie@vates.tech \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.