[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 6/7] x86: add iommu_op to query reserved ranges
>>> 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |