Now that the iommu_map() and iommu_unmap() operations take an order
parameter and elide flushing there's no strong reason why modifying MMIO
ranges in the p2m should be restricted to a 4k granularity simply because
the IOMMU is enabled but shared page tables are not in operation.
Signed-off-by: Paul Durrant <paul.durr...@citrix.com>
Reviewed-by: Jan Beulich <jbeul...@suse.com>
---
Cc: George Dunlap <george.dun...@eu.citrix.com>
Cc: Andrew Cooper <andrew.coop...@citrix.com>
Cc: Wei Liu <wei.l...@citrix.com>
Cc: "Roger Pau Monné" <roger....@citrix.com>
v2:
- New in v2. (Adapted from a previously independent patch).
---
xen/arch/x86/mm/p2m.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index ed76e96d33..a9cfd1b2e4 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2059,13 +2059,12 @@ static unsigned int mmio_order(const struct domain *d,
unsigned long start_fn, unsigned long nr)
{
/*
- * Note that the !iommu_use_hap_pt() here has three effects:
- * - cover iommu_{,un}map_page() not having an "order" input yet,
+ * Note that the !hap_enabled() here has two effects:
* - exclude shadow mode (which doesn't support large MMIO mappings),
* - exclude PV guests, should execution reach this code for such.
* So be careful when altering this.
*/
- if ( !iommu_use_hap_pt(d) ||
+ if ( !hap_enabled(d) ||
(start_fn & ((1UL << PAGE_ORDER_2M) - 1)) || !(nr >> PAGE_ORDER_2M) )
return PAGE_ORDER_4K;
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
