Messages in this thread | | | From | "Tian, Kevin" <> | Subject | RE: [RFC 11/20] iommu/iommufd: Add IOMMU_IOASID_ALLOC/FREE | Date | Wed, 13 Oct 2021 07:07:34 +0000 |
| |
> From: Jean-Philippe Brucker <jean-philippe@linaro.org> > Sent: Monday, October 11, 2021 4:50 PM > > On Mon, Oct 11, 2021 at 05:02:01PM +1100, David Gibson wrote: > > qemu wants to emulate a PAPR vIOMMU, so it says (via interfaces yet to > > be determined) that it needs an IOAS where things can be mapped in the > > range 0..2GiB (for the 32-bit window) and 2^59..2^59+1TiB (for the > > 64-bit window). > > > > Ideally the host /dev/iommu will say "ok!", since both those ranges > > are within the 0..2^60 translated range of the host IOMMU, and don't > > touch the IO hole. When the guest calls the IO mapping hypercalls, > > qemu translates those into DMA_MAP operations, and since they're all > > within the previously verified windows, they should work fine. > > Seems like we don't need the negotiation part? The host kernel > communicates available IOVA ranges to userspace including holes (patch > 17), and userspace can check that the ranges it needs are within the IOVA > space boundaries. That part is necessary for DPDK as well since it needs > to know about holes in the IOVA space where DMA wouldn't work as > expected > (MSI doorbells for example). And there already is a negotiation happening, > when the host kernel rejects MAP ioctl outside the advertised area. >
Agree. This can cover the ppc platforms with fixed reserved ranges. It's meaningless to have user further tell kernel that it is only willing to use a subset of advertised area. for ppc platforms with dynamic reserved ranges which are claimed by user, we can leave it out of the common set and handled in a different way, either leveraging ioas nesting if applied or having ppc specific cmd.
Thanks Kevin
| |