On 10/02/2021 08:50, Julien Grall wrote:
Hi Roger,
On 10/02/2021 08:29, Roger Pau Monné wrote:
On Tue, Feb 09, 2021 at 03:28:12PM +0000, Julien Grall wrote:
From: Julien Grall <jgr...@amazon.com>
Currently, the IOMMU page-tables will be populated early in the domain
creation if the hardware is able to virtualize the local APIC. However,
the IOMMU page tables will not be freed during early failure and will
result to a leak.
An assigned device should not need to DMA into the vLAPIC page, so we
can avoid to map the page in the IOMMU page-tables.
This statement is also true for any special pages (the vLAPIC page is
one of them). So to take the opportunity to prevent the mapping for all
of them.
Hm, OK, while I assume it's likely for special pages to not be target
of DMA operations, it's not easy to spot what are special pages.
Special pages are allocated by Xen for grant-table, vCPU info...
Note that:
- This is matching the existing behavior with PV guest
You might make HVM guests not sharing page-tables 'match' PV
behavior, but you are making behavior between HVM guests themselves
diverge.
- This doesn't change the behavior when the P2M is shared with the
IOMMU. IOW, the special pages will still be accessibled by the
device.
I have to admit I don't like this part at all. Having diverging device
mappings depending on whether the page tables are shared or not is
bad IMO, as there might be subtle bugs affecting one of the two
modes.
I get the feeling this is just papering over an existing issue instead
of actually fixing it: IOMMU page tables need to be properly freed
during early failure.
My initial approach was to free the IOMMU page tables during early
failure (see [1] and [2]). But Jan said the special pages should really
not be mapped in the IOMMU ([3]) and he wasn't very happy with freeing
the IOMMU pages table for early failure.
I don't particularly care about the approach as long as we don't leak
IOMMU page-tables at the end.
So please try to find a common ground with Jan here.
Cheers,
[1] <20201222154338.9459-1-jul...@xen.org>
[2] <20201222154338.9459-5-jul...@xen.org>
Roger pointed out on IRC that I forgot to add a link for [3]. So here we go:
[3] <a22f7364-518f-ea5f-3b87-5c0462cfc...@suse.com>
Cheers,
--
Julien Grall