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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Roger Pau Monne
> Sent: 16 October 2018 17:27
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; George Dunlap
> <George.Dunlap@xxxxxxxxxx>; Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; Wei
> Liu <wei.liu2@xxxxxxxxxx>; Jan Beulich <jbeulich@xxxxxxxx>
> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel