[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 06/13] iommu: Add extra use_iommu argument to iommu_domain_init()
>>> On 07.12.17 at 13:08, <olekstysh@xxxxxxxxx> wrote: > On Thu, Dec 7, 2017 at 12:49 AM, Julien Grall <julien.grall@xxxxxxxxxx> wrote: >> On 12/06/2017 07:53 PM, Oleksandr Tyshchenko wrote: >>> On Wed, Dec 6, 2017 at 6:51 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote: >>>>>>> >>>>>>> On 25.07.17 at 19:26, <olekstysh@xxxxxxxxx> wrote: >>>>> >>>>> The presence of this flag lets us know that the guest domain has >>>>> statically >>>>> assigned devices which will most likely be used for passthrough >>>>> and as the result the IOMMU is expected to be used for this domain. >>>>> >>>>> Taking into the account this hint when dealing with non-shared IOMMUs >>>>> we can populate IOMMU page tables before hand avoid going through >>>>> the list of pages at the first assigned device. >>>>> As this flag doesn't cover hotplug case, we will continue to populate >>>>> IOMMU page tables on the fly. >>>> >>>> >>>> While of course it would have been nice if I would have found time >>>> earlier to look at this patch (and hence closer to when the discussion >>>> happened), I still don't see it being made sufficiently clear here why >>>> current behavior (without a need for such a flag) is a problem for the >>>> non-shared IOMMU case on ARM, when it isn't on x86. >>> >>> >>> The answer is the lack of M2P on ARM. When the first device is being >>> assigned to domain we are populating non-shared IOMMU page-table. >>> What does it mean? We are iterating through the list of the pages >>> (d->page_list) and retrieving a pair of mfn <-> gfn for each page on >>> x86. >>> We can't do the same on ARM, since there is no M2P table. The >>> mfn_to_gmfn macros is just a stub: >>> #define mfn_to_gmfn(_d, mfn) (mfn) >>> >>> To be honest I haven't played with non-shared IOMMU on ARM >>> since the end of this summer to be 100% sure that it is still an >>> issue. But, it seems to be. >> >> >> The situation has not changed. I still see no point of waste memory for the >> M2P (see the full discussion here [1]). >> >> However, I agree with Jan that we need a summary of the discussion in the >> commit message. > Sure. > > Jan, is the clarification I have provided (why it is a problem for the > non-shared IOMMU case on ARM, when it isn't on x86) sufficiently clear and Yes, mentioning the lack of M2P is goin g to be sufficient rationale. > the current patch with "updated" commit message will be ready to get your > ack? I think so, albeit I haven't fully settled yet whether to push back on the ARM folks not wanting to introduce M2P. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |