From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42640) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0xag-000148-Gp for qemu-devel@nongnu.org; Mon, 23 Nov 2015 15:19:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0xac-0007un-IE for qemu-devel@nongnu.org; Mon, 23 Nov 2015 15:19:58 -0500 Received: from mx5-phx2.redhat.com ([209.132.183.37]:37878) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0xac-0007uj-AZ for qemu-devel@nongnu.org; Mon, 23 Nov 2015 15:19:54 -0500 Date: Mon, 23 Nov 2015 15:19:49 -0500 (EST) From: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Message-ID: <727042122.15766374.1448309989580.JavaMail.zimbra@redhat.com> In-Reply-To: <56536E89.4090408@redhat.com> References: <87si401wpf.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> <56536E89.4090408@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: Eric Blake Cc: marcandre lureau , Luiz Capitulino , Claudio Fontana , Markus Armbruster , qemu-devel@nongnu.org Hi ----- Original Message ----- > On 11/23/2015 07:46 AM, Markus Armbruster wrote: > > >>> 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. > > > > That's not a complete answer, so let me try a different tack. > > > > What value will a read of register IVPosition yield > > > > * if the device has no doorbell: > > > > I think the answer is -1. > > > > * if the device has a doorbell, but it isn't ready, yet: > > > > I think the answer is -1. > > > > * if the device has a doorbell, and it is ready. > > > > This is the part you answered already: >= 0. > > > > Please correct mistakes. > > For what it's worth, I'm agreeing with Markus here - we have a race in > the guest learning whether doorbell is supported, and it's better to do I think there is no race if you communicate this information in the shared memory. > a clean break in API for 2.5 along with ALL the other fixes into using a > sane union of types (splitting between ivshmem-plain and > ivshmem-doorbell). If you absolutely want it, you can still maintain > 'ivshmem' as a front-end that maps to either ivshmem-plain, > ivshmem-doorbell, or an error (nonsensical combination of requests), but It's not about me. Until now I was not aware of anyone complaining about the ivshmem interface, but by its implementation. I tried to adress all the issues and comments I have found, and I tried to make sure not to break stuff, because I usually receive huge complains whenever I do, and I have to throw up the work. So if there is a consensus to break things now, I think it's quite late for this cycle, but I am for it. > having a sane interface as your starting point, rather than an > amalgamation of cruft that exists only due to the early implementation, > seems like the way to go. It is just the way it was, isn't it? > I'm still waiting for any evidence that we even care about backwards > compatibility - what apps are out there that are actively using ivshmem > with its horrible pre-2.5 interface, and why can they not be fixed to > use the sane 2.5 interface? Libvirt is NOT exposing ivshmem yet, in > part because the 2.4 interface was not very robust. We already have a Afaik it's there since 1.2.10 > clean break now due to all your work for 2.5; let's take advantage of > it, and make 2.5 robust, rather than breaking things again in 2.6. 2.5 should not break the ivshmem interface.