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 <[email protected]> Reviewed-by: Jan Beulich <[email protected]> --- Cc: George Dunlap <[email protected]> Cc: Andrew Cooper <[email protected]> Cc: Wei Liu <[email protected]> Cc: "Roger Pau Monné" <[email protected]> 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 [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
