Re: [Xen-devel] [PATCH 6/7] x86: add iommu_op to query reserved ranges

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 19.03.18 at 16:13, <Paul.Durrant@xxxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: 19 March 2018 14:10
>> 
>> >>> On 12.02.18 at 11:47, <paul.durrant@xxxxxxxxxx> wrote:
>> > +                for ( j = 0; \
>> > +                      j < min_t(unsigned int, (_d_)->nr_entries, \
>> > +                                *nr_entries); \
>> 
>> Do you really need min_t() here (rather than the more safe min())?
>> 
> 
> I've been asked to preferentially use min_t() before (although I don't think 
> it was by you) so I'm not sure what the expectation is. I'm happy to use 
> min().

I'd be curious who that was and why. The type check in min() makes
it preferable to use whenever the two types are (supposed to be)
compatible.

>> > +struct xen_iommu_reserved_region {
>> > +    xen_bfn_t start_bfn;
>> > +    unsigned int nr_frames;
>> > +    unsigned int pad;
>> 
>> Fixed width types (i.e. uint32_t) in the public interface please.
>> Also, this not being the main MMU, page granularity needs to be
>> specified somehow (also for the conversion between xen_bfn_t
>> and a bus address).
>> 
> 
> Do you think it would be better to have a separate query call to get the 
> IOMMU page size back, or are you anticipating heterogeneous ranges (in which 
> case I'm going to need to adjust the map and unmap functions to allow for 
> that)?

Fundamentally (on x86) I can't see why we couldn't eventually
permit 2M and 1G mappings to be established this way. For
RMRRs I don't know how large they can get. I think I've seen
larger than single pages ones for graphics devices, but I don't
recall how big they were, or whether they were suitable aligned
to allow large page mappings.

But we should also have ARM (and ideally make this abstract
enough to even fit other architectures) in mind. Also remember
that someone already has a series somewhere to extend the
iommu_{,un}map_page() functions with an order parameter.

Jan


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