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