[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] IOMMU/x86: don't map IO-APICs for PV Dom0
On 16.08.2021 20:31, Andrew Cooper wrote: > On 16/08/2021 16:31, Jan Beulich wrote: >> While already the case for PVH, there's no reason to treat PV >> differently here (except of course where to take the addresses from). >> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> > > Honestly, this is already a mess but I think the change is making things > worse rather than better. > > To start with, IO-APIC windows are 1k not 4k, except that no-one added a > "4k safe" flag because IO-APICs weren't mapped into userspace by Linux > at the time. > > More generally though, if something is safe to let dom0 map in the CPU > pagetables, it is safe to go in the IOMMU pagetables. Conversely, if > it's not safe to go in one, it's not safe to go in either. > > Mappings (or at least mapability) of everything/anything should be > uniform between the CPU and IOMMU pagetables for any kind of sanity to > prevail. Just in case it's not obvious (it just occurred to me to mention it): There's a similar inconsistency with all other MMIO: HVM/PVH get this mapped in both CPU and IOMMU, while PV doesn't. If mappings were mirrored to the IOMMU, the patch here wouldn't be necessary in its v2 form (or the form when integrated into the larger series), but instead would be correct in this initial shape. So if you think that's the way to go, I can restore the initial version of this patch after adding a prereq one to mirror MMIO page mappings to the IOMMU. There's one difficulty though: We'd need to have a way to tell when it's safe to unmap from the IOMMU again. In case of multiple CPU side mappings we can't unmap when the first of these mappings goes away. Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |