[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] iommu: specify page_count rather than page_order to iommu_map/unmap()...

>>> On 22.01.19 at 19:23, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 22/01/2019 10:46, Jan Beulich wrote:
>>> Regardless of the 
>>> alignment though, the fact that order comes from a hypercall argument and 
>>> may 
>>> not match any of the orders supported by the IOMMU implementation makes me 
>>> think that using a page count is better.
>> Splitting up guest requests is orthogonal to whether a count or an
>> order is more suitable as a parameter.
> No - this is most certainly not true.
> Any arbitrary mapping can be expressed with a single map call, given a
> start/count.  This is not true of a start/order pair, so start/count is
> strictly more expressive.
> Furthermore, I've already given the following concrete options as to why
> start/count is better than start/order:  Reduced caller looping,

That depends on how many callers are actually affected. Hence my
request for concrete examples. I'm about to look into what Roger's
latest reply is meaning in this regard.

> reduced TLB flushing in the current implementation,

I'm afraid I lack the connection to the amount of TLB flushing done.

> and the fact we literally have hypercalls using this mechanism who's
> API is stable.

Hmm, would you mind helping me with this? All the memop-s are
using order values as input. XEN_DOMCTL_memory_mapping is
not a stable interface. What else do we have that I can't seem
to recall?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.