From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MThTv-0005jr-O0 for qemu-devel@nongnu.org; Wed, 22 Jul 2009 15:28:03 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MThTr-0005jR-Vn for qemu-devel@nongnu.org; Wed, 22 Jul 2009 15:28:03 -0400 Received: from [199.232.76.173] (port=56604 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MThTr-0005jO-QS for qemu-devel@nongnu.org; Wed, 22 Jul 2009 15:27:59 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:60157) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MThTq-0002gx-BN for qemu-devel@nongnu.org; Wed, 22 Jul 2009 15:27:59 -0400 Message-ID: <4A676839.8050500@web.de> Date: Wed, 22 Jul 2009 21:27:53 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <200907221626.n6MGQGH0022104@d03av02.boulder.ibm.com> <4A6745C0.5060201@siemens.com> <4A675758.2080302@codemonkey.ws> In-Reply-To: <4A675758.2080302@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2B71FE90714350BE972814AA" Sender: jan.kiszka@web.de Subject: [Qemu-devel] [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: Anthony Liguori Cc: Anthony Liguori , qemu-devel , Alexander Graf This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2B71FE90714350BE972814AA Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Anthony Liguori wrote: > Jan Kiszka wrote: >>> Signed-off-by: Alexander Graf >>> Signed-off-by: Anthony Liguori >>> >>> >>> diff --git a/kvm-all.c b/kvm-all.c >>> index 961fa32..2032949 100644 >>> --- a/kvm-all.c >>> +++ b/kvm-all.c >>> @@ -300,6 +300,7 @@ int >>> kvm_physical_sync_dirty_bitmap(target_phys_addr_t start_addr, >>> KVMDirtyLog d; >>> KVMSlot *mem; >>> int ret =3D 0; >>> + int r; >>> =20 >>> d.dirty_bitmap =3D NULL; >>> while (start_addr < end_addr) { >>> @@ -308,6 +309,11 @@ int >>> kvm_physical_sync_dirty_bitmap(target_phys_addr_t start_addr, >>> break; >>> } >>> =20 >>> + /* We didn't activate dirty logging? Don't care then. */ >>> + if(!(mem->flags & KVM_MEM_LOG_DIRTY_PAGES)) { >>> + continue; >>> + } >>> + >>> =20 >> >> According to Alex' reply [1], I think this is probably better expresse= d >> as an assert() than a silent skip. It indicates an error at higher >> level, no? >> =20 >=20 > I don't have a strong opinion either way. >=20 >>> size =3D ((mem->memory_size >> TARGET_PAGE_BITS) + 7) / 8; >>> if (!d.dirty_bitmap) { >>> d.dirty_bitmap =3D qemu_malloc(size); >>> @@ -319,7 +325,8 @@ int >>> kvm_physical_sync_dirty_bitmap(target_phys_addr_t start_addr, >>> =20 >>> d.slot =3D mem->slot; >>> =20 >>> - if (kvm_vm_ioctl(s, KVM_GET_DIRTY_LOG, &d) =3D=3D -1) { >>> + r =3D kvm_vm_ioctl(s, KVM_GET_DIRTY_LOG, &d); >>> + if (r =3D=3D -EINVAL) { >>> dprintf("ioctl failed %d\n", errno); >>> ret =3D -1; >>> break; >>> =20 >> >> My remark still stands: This is an "optimistic" assumption that only >> EINVAL is a "real" error. If KVM is buggy /wrt a specific invalid retu= rn >> value, work around that particular bug (and we should also fix the >> kernel, but that's a different topic). >> =20 >=20 > The behavior is identical to what it was before. It's just a stylistic= > change. Not really (EINVAL !=3D 1). But, yes, it's incorrect in similar way. :) Jan -----------> Signed-off-by: Jan Kiszka --- kvm-all.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/kvm-all.c b/kvm-all.c index 824bb4c..53925be 100644 --- a/kvm-all.c +++ b/kvm-all.c @@ -348,7 +348,9 @@ int kvm_physical_sync_dirty_bitmap(target_phys_addr_t= start_addr, d.slot =3D mem->slot; =20 r =3D kvm_vm_ioctl(s, KVM_GET_DIRTY_LOG, &d); - if (r =3D=3D -EINVAL) { + /* KVM for PowerPC returns illicit -ENOTSUPP (-524) which we han= dle + * below. */ + if (r < 0 && r !=3D -524) { dprintf("ioctl failed %d\n", errno); ret =3D -1; break; --------------enig2B71FE90714350BE972814AA 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 iEYEARECAAYFAkpnaDwACgkQniDOoMHTA+nl8QCdH4hwmTXZZfirYV5OZEJcOK2V DF0An2mTWgNd6O/2DHRp+CgJalcfwlfg =oLQQ -----END PGP SIGNATURE----- --------------enig2B71FE90714350BE972814AA--