|
[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 Thu, Dec 7, 2017 at 12:49 AM, Julien Grall <julien.grall@xxxxxxxxxx> wrote: > Hi, Hi Julien, Jan > > > 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 the current patch with "updated" commit message will be ready to get your ack? > >>> >>> The patch itself looks mechanical enough that it could get my ack, >>> but I really want to understand the background without having to >>> dig out old discussions (which would be even more difficult for >>> future archaeologists running into this change in a few years time). > > > Cheers, > > [1] https://lists.xen.org/archives/html/xen-devel/2017-05/msg01737.html > > -- > Julien Grall -- Regards, Oleksandr Tyshchenko _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |