> From: Jean-Philippe Brucker <jean-philippe@xxxxxxxxxx> > 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
