Re: [Xen-devel] [PATCH] x86/mm/p2m: don't needlessly limit MMIO mapping order to 4k

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Tue, Oct 16, 2018 at 03:41:55PM +0100, Paul Durrant wrote:
> The P2M common code currently restricts the MMIO mapping order of any
> domain with IOMMU mappings, but that is not using shared tables, to 4k.
> This has been shown to have a huge performance cost when passing through
> a PCI device with a very large BAR (e.g. NVIDIA P40), increasing the guest
> boot time from ~20s to several minutes when iommu=no-sharept is specified
> on the Xen command line.
> 
> The limitation was added by commit c3c756bd "x86/p2m: use large pages
> for MMIO mappings" however the underlying implementations of p2m->set_entry
> for Intel and AMD are coded to cope with mapping orders higher than 4k,
> even though the IOMMU mapping function is itself currently limited to 4k,
> so there is no real need to limit the order passed into the method.
> 
> With this patch applied the VM boot time is restored to something
> reasonable. Not as fast as without iommu=no-sharept, but within a few
> seconds of it.

I guess the worry was that the loop in for example ept_set_entry to
perform the iommu mappings would take too long and trigger the
watchdog if for example a 1GB page is mapped?

In any case we already allow to map higher order non-MMIO pages, which
should also trigger such issue?

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel