From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:48375)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from
) id 1ZxAjM-0006PM-Pn
for qemu-devel@nongnu.org; Fri, 13 Nov 2015 04:33:21 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from ) id 1ZxAjJ-0007V4-Ie
for qemu-devel@nongnu.org; Fri, 13 Nov 2015 04:33:16 -0500
Received: from mailout2.w1.samsung.com ([210.118.77.12]:13152)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from ) id 1ZxAjJ-0007UB-DO
for qemu-devel@nongnu.org; Fri, 13 Nov 2015 04:33:13 -0500
Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244])
by mailout2.w1.samsung.com
(Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5
2014)) with ESMTP id <0NXQ00D65YJA9Z80@mailout2.w1.samsung.com> for
qemu-devel@nongnu.org; Fri, 13 Nov 2015 09:33:10 +0000 (GMT)
From: Pavel Fedin
References: <00fb01d11d19$fc458f20$f4d0ad60$@samsung.com>
<1447337819.3946.35.camel@redhat.com>
<014c01d11d57$5a101a20$0e304e60$@samsung.com>
<1447342408.3946.54.camel@redhat.com>
In-reply-to: <1447342408.3946.54.camel@redhat.com>
Date: Fri, 13 Nov 2015 12:33:09 +0300
Message-id: <002401d11df6$4f7282c0$ee578840$@samsung.com>
MIME-version: 1.0
Content-type: text/plain; charset=UTF-8
Content-transfer-encoding: quoted-printable
Content-language: ru
Subject: Re: [Qemu-devel] [PATCH] vfio: Fix
handling VFIO_IOMMU_GET_INFO results
List-Id:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
To: 'Alex Williamson'
Cc: qemu-devel@nongnu.org
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 The Boss, so you can just say "i don't care". So,
> > just let me now if you strongly disagree with this.
>=20
> I do care, in fact I care enough about the ABI that I'm suggesting =
what
> I think is the correct fix rather than taking the quick and dirty
> solution. It's an unfortunate bug, but it's not worth changing the =
ABI
> and removing the kernel's ability to indicate whether the pgsize =
bitmap
> field is valid IMO.
Ok, i see your point...
But what about fix, which would work both with future kernels, which do =
provide this flag, as well as would be compatible with already existing =
kernels, which set flags =3D=3D 0?
We could check for ((info.flags =3D=3D 0) || (info.flags & =
VFIO_IOMMU_INFO_PGSIZES)). This would conform to both behaviors:
a) All current kernels set flags =3D 0 and report page sizes.
b) Some future kernels could have set some flags, but not reported page =
sizes and not set VFIO_IOMMI_PGSIZES
What would you say about this? Yes, this would be a "workaround" =
instead of "fix".
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia