We currently send all mappings to the iommu in PAGE_SIZE chunks,
which prevents the iommu from enabling support for larger page sizes.
We still need to pin pages, which means we step through them in
PAGE_SIZE chunks, but we can batch up contiguous physical memory
chunks to allow the iommu the oppor
> + * Turns out AMD IOMMU has a page table bug where it won't map large pages
> + * to a region that previously mapped smaller pages. This should be fixed
> + * soon, so this is just a temporary workaround to break mappings down into
> + * PAGE_SIZE. Better to map smaller pages than nothing.
> +
On Sat, 2013-05-25 at 07:20 -0400, Konrad Rzeszutek Wilk wrote:
> > + * Turns out AMD IOMMU has a page table bug where it won't map large pages
> > + * to a region that previously mapped smaller pages. This should be fixed
> > + * soon, so this is just a temporary workaround to break mappings down
vi...@hp.com; qemu-
> de...@nongnu.org; kvm@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: [PATCH 2/2] vfio: hugepage support for vfio_iommu_type1
>
> We currently send all mappings to the iommu in PAGE_SIZE chunks, which
> prevents the iommu from enabling support for larg
:55 PM
> > To: alex.william...@redhat.com
> > Cc: io...@lists.linux-foundation.org; chegu_vi...@hp.com; qemu-
> > de...@nongnu.org; kvm@vger.kernel.org; linux-ker...@vger.kernel.org
> > Subject: [PATCH 2/2] vfio: hugepage support for vfio_iommu_type1
> >
> > We curr
