On Fri, 2015-11-13 at 12:33 +0300, Pavel Fedin wrote:
> Hello!
>
> > > If we fix qemu, it will automatically start working with all
> > > available kernels which are there in the wild. If we fix kernel, older
> > > versions will still not work, however they can.
> > > That's why i think that we
Hello!
> > If we fix qemu, it will automatically start working with all
> > available kernels which are there in the wild. If we fix kernel, older
> > versions will still not work, however they can.
> > That's why i think that we should adapt qemu to what already exists.
> > But, well, you are
On Thu, 2015-11-12 at 17:35 +0300, Pavel Fedin wrote:
> Hello!
>
> > > Kernel headers define VFIO_IOMMU_INFO_PGSIZES flag, however it has
> > > actually been never used, probably by mistake which now became a part
> > > of the ABI. The kernel always sets info.flags to 0:
> >
> > I don't see how
Hello!
> > Kernel headers define VFIO_IOMMU_INFO_PGSIZES flag, however it has
> > actually been never used, probably by mistake which now became a part
> > of the ABI. The kernel always sets info.flags to 0:
>
> I don't see how this implies that it becomes part of the ABI. In fact,
> as the def
On Thu, 2015-11-12 at 10:16 +0300, Pavel Fedin wrote:
> Kernel headers define VFIO_IOMMU_INFO_PGSIZES flag, however it has
> actually been never used, probably by mistake which now became a part
> of the ABI. The kernel always sets info.flags to 0:
I don't see how this implies that it becomes part
Kernel headers define VFIO_IOMMU_INFO_PGSIZES flag, however it has
actually been never used, probably by mistake which now became a part
of the ABI. The kernel always sets info.flags to 0:
http://lxr.free-electrons.com/source/drivers/vfio/vfio_iommu_type1.c?v=3.7#L675
http://lxr.free-electrons.com
