Re: [Xen-devel] [PATCH v2 06/13] iommu: Add extra use_iommu argument to iommu_domain_init()

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi,

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.
> > 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel