From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37722) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0srg-0007md-SF for qemu-devel@nongnu.org; Mon, 23 Nov 2015 10:17:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0src-0002PB-P8 for qemu-devel@nongnu.org; Mon, 23 Nov 2015 10:17:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50268) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0src-0002Ow-HW for qemu-devel@nongnu.org; Mon, 23 Nov 2015 10:17:08 -0500 From: Markus Armbruster References: <87si401wpf.fsf@blackfin.pond.sub.org> <87oael587p.fsf@blackfin.pond.sub.org> <802808837.15238786.1448280956337.JavaMail.zimbra@redhat.com> <87r3jg26fw.fsf@blackfin.pond.sub.org> <1032710289.15307566.1448286512454.JavaMail.zimbra@redhat.com> <87610sx0zd.fsf@blackfin.pond.sub.org> <560475200.15358637.1448288207922.JavaMail.zimbra@redhat.com> <87mvu4srid.fsf@blackfin.pond.sub.org> <1051241523.15423297.1448290406693.JavaMail.zimbra@redhat.com> Date: Mon, 23 Nov 2015 16:17:05 +0100 In-Reply-To: <1051241523.15423297.1448290406693.JavaMail.zimbra@redhat.com> (=?utf-8?Q?=22Marc-Andr=C3=A9?= Lureau"'s message of "Mon, 23 Nov 2015 09:53:26 -0500 (EST)") Message-ID: <87vb8soidq.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] ivshmem property size should be a size, not a string List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Cc: marcandre lureau , Claudio Fontana , qemu-devel@nongnu.org, Luiz Capitulino Marc-Andr=C3=A9 Lureau writes: > ----- Original Message ----- >> Marc-Andr=C3=A9 Lureau writes: >>=20 >> > Hi >> > >> > ----- Original Message ----- >> >> > >> >> > You can't migrate the peers. >> >>=20 >> >> Then explain the case N'=3D0 to me: how can you migrate the master so= that >> >> it's connected to a server afterwards? >> > >> > Dest qemu: -incoming.. -chardev socket,path=3Ddest-server >> > >> > That is, start your destination qemu with a destination server. The ma= ster >> > origin qemu will migrate the shared memory, and the dest memory will be >> > sync >> > when the migration is done. >>=20 >> Got it! >>=20 >> >> > It works fine in the tests. Feel free to point out races or other >> >> > issues. >> >>=20 >> >> I think I did: doorbell detection is inherently racy. >> >>=20 >> >> If you think it isn't, please refute my reasoning. >> > >> > I gave you some clues on how I did it in ivshmem-test.c: waiting for a >> > signature on the memory to be mapped (and also checking that peers >> > received ids) >> > >> >> If it's not broken, please explain to me how the guest should find out >> >> whether its ivshmem device sports a doorbell. >> > >> > If you have received ID, you should be good to use the doorbell. >>=20 >> That's not a complete answer, so let me try a different tack. >>=20 >> What value will a read of register IVPosition yield >>=20 >> * if the device has no doorbell: >>=20 >> I think the answer is -1. >>=20 >> * if the device has a doorbell, but it isn't ready, yet: >>=20 >> I think the answer is -1. >>=20 >> * if the device has a doorbell, and it is ready. >>=20 >> This is the part you answered already: >=3D 0. >>=20 >> Please correct mistakes. >>=20 > > Yes, I think it's correct. Arbitrary informations can be then shared > via the shared memory (to say whether a doorbell will be present for > ex). Then there is no race-free way for the guest to distinguish between "no doorbell" and "doorbell not ready" without some higher-level protocol. Corollary: when IVPosition reads -1, BAR 2 may or may not be mapped, and the only way to find out is accessing it. Feels plenty broken to me. Straight NAK in fact if it wasn't already in the tree.