> -----Original Message----- > From: Roger Pau Monne > Sent: 16 October 2018 17:27 > To: Paul Durrant <paul.durr...@citrix.com> > Cc: xen-devel@lists.xenproject.org; George Dunlap > <george.dun...@citrix.com>; Andrew Cooper <andrew.coop...@citrix.com>; Wei > Liu <wei.l...@citrix.com>; Jan Beulich <jbeul...@suse.com> > Subject: Re: [Xen-devel] [PATCH] x86/mm/p2m: don't needlessly limit MMIO > mapping order to 4k > > 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?
Indeed. It's no different at this level. AFAICT we map an extent of whatever order is handed to XENMEM_populate_physmap with no pre-empt checks so, if there is a problem, limiting the MMIO order does not seem to be the right way to deal with it. Paul > > Thanks, Roger. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
