Re: [Xen-devel] [PATCH v2 4/4] x86/mm/p2m: stop checking for IOMMU shared page tables in mmio_order()
>>> On 03.12.18 at 18:40, wrote: > 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 Based on the other reply of yours: Reviewed-by: Jan Beulich Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 4/4] x86/mm/p2m: stop checking for IOMMU shared page tables in mmio_order()
>>> On 04.12.18 at 16:22, wrote: >> -Original Message- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 04 December 2018 15:21 >> To: Paul Durrant >> Cc: Andrew Cooper ; Roger Pau Monne >> ; Wei Liu ; George Dunlap >> ; xen-devel >> Subject: Re: [PATCH v2 4/4] x86/mm/p2m: stop checking for IOMMU shared >> page tables in mmio_order() >> >> >>> On 03.12.18 at 18:40, wrote: >> > 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. >> >> I'm afraid the two improvements are not enough for this restriction >> to be lifted: There's still no preemption in the processing of the >> higher order values. > > Why? 1G orders are already ruled out and testing shows that 2M orders cause > no problems on EPYC systems. Hmm, yes, agreed. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 4/4] x86/mm/p2m: stop checking for IOMMU shared page tables in mmio_order()
> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 04 December 2018 15:21 > To: Paul Durrant > Cc: Andrew Cooper ; Roger Pau Monne > ; Wei Liu ; George Dunlap > ; xen-devel > Subject: Re: [PATCH v2 4/4] x86/mm/p2m: stop checking for IOMMU shared > page tables in mmio_order() > > >>> On 03.12.18 at 18:40, wrote: > > 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. > > I'm afraid the two improvements are not enough for this restriction > to be lifted: There's still no preemption in the processing of the > higher order values. Why? 1G orders are already ruled out and testing shows that 2M orders cause no problems on EPYC systems. Paul > > Jan > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 4/4] x86/mm/p2m: stop checking for IOMMU shared page tables in mmio_order()
>>> On 03.12.18 at 18:40, wrote: > 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. I'm afraid the two improvements are not enough for this restriction to be lifted: There's still no preemption in the processing of the higher order values. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
