From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MTj91-0004My-Vv for qemu-devel@nongnu.org; Wed, 22 Jul 2009 17:14:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MTj8x-0004HC-EN for qemu-devel@nongnu.org; Wed, 22 Jul 2009 17:14:35 -0400 Received: from [199.232.76.173] (port=35790 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTj8w-0004Gv-Tw for qemu-devel@nongnu.org; Wed, 22 Jul 2009 17:14:31 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:60556) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MTj8w-0006RG-F0 for qemu-devel@nongnu.org; Wed, 22 Jul 2009 17:14:30 -0400 Message-ID: <4A678130.6080502@web.de> Date: Wed, 22 Jul 2009 23:14:24 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <200907221626.n6MGQGH0022104@d03av02.boulder.ibm.com> <4A6745C0.5060201@siemens.com> <4A675758.2080302@codemonkey.ws> <4A676839.8050500@web.de> <4A676897.5070200@us.ibm.com> <4A676B27.10100@web.de> <4A676B98.1060104@us.ibm.com> <4A67719F.9040803@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAB34A05B9B6DDA86F4EE28D8" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [PATCH] kvm: Fix error detection for KVM_GET_DIRTY_LOG List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Anthony Liguori , qemu-devel This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAB34A05B9B6DDA86F4EE28D8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alexander Graf wrote: >=20 >=20 >=20 >=20 > Am 22.07.2009 um 22:07 schrieb Jan Kiszka : >=20 >> Anthony Liguori wrote: >>> Jan Kiszka wrote: >>>>> That makes me uncomfortable. Shouldn't we make kvm return somethin= g >>>>> that's exposed to userspace? >>>>> >>>>> >>>> >>>> Yes, but we can't do this from user space :) (or in other words: the= re >>>> are already kernels out there which return this invalid code). >>>> >>> >>> But since it's not symbolic, at some point in time the meaning of 524= >>> can potentially change and introduce a very, very subtle bug. >> >> I won't change in old kernel versions, and I expect someone from the >> PowerPC folks to fix it for new version fairly soon. >> >>> >>>> The situation would only be different if Alex said that it takes >>>> further >>>> kernel patches anyway to make his PowerPC targets work. Dunno. >>>> >>> >>> Certainly, his PPC target is not in any released kernel version so >>> there's time to fix things properly. >> >> Ah, ok. Then let's do this (Alex can carry a temporary workaround >> locally IMHO): >> >> -------------> >> >> Signed-off-by: Jan Kiszka >> --- >> >> kvm-all.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/kvm-all.c b/kvm-all.c >> index 824bb4c..5fb8dba 100644 >> --- a/kvm-all.c >> +++ b/kvm-all.c >> @@ -348,7 +348,7 @@ int >> kvm_physical_sync_dirty_bitmap(target_phys_addr_t start_addr, >> d.slot =3D mem->slot; >> >> r =3D kvm_vm_ioctl(s, KVM_GET_DIRTY_LOG, &d); >> - if (r =3D=3D -EINVAL) { >> + if (r < 0) { >=20 > That's worse as it essentially removes the not implemented case. You can add the valid return code of a fixed powerpc version of kvm_vm_ioctl_get_dirty_log here. >=20 > The only thing I'd agree with as a good idea instead of the version I > sent is an explicit switch statement with an include of errno.h with > __KERNEL__ set. Sorry, that's also horrible. Again the question: Is there already some official, unpatched kernel version which would work with QEMU if we only handle that borken ENOTSUPP case? If not, I see no point in handling it here. Please fix KVM and provide a patch that checks for the fixed, valid error code. If there is such a kernel, I see no problem with hard-coding ENOTSUPP's value now, as we are working around a hard-coded bug that will no longer exist in the future (where ENOTSUPP may change its value - theoretically)= =2E Jan --------------enigAB34A05B9B6DDA86F4EE28D8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkpngTQACgkQniDOoMHTA+nOxACfQz9QO829AdcbDJ2HYpb4nJp6 iHIAn2CEA8kJqDEacS83uWKqgQsKSxsz =aBLX -----END PGP SIGNATURE----- --------------enigAB34A05B9B6DDA86F4EE28D8--