From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46225) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0q2T-0007Cc-0R for qemu-devel@nongnu.org; Mon, 23 Nov 2015 07:16:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0q2N-0000qB-Ts for qemu-devel@nongnu.org; Mon, 23 Nov 2015 07:16:08 -0500 Received: from mx4-phx2.redhat.com ([209.132.183.25]:55619) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0q2N-0000q5-Mf for qemu-devel@nongnu.org; Mon, 23 Nov 2015 07:16:03 -0500 Date: Mon, 23 Nov 2015 07:15:56 -0500 (EST) From: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Message-ID: <802808837.15238786.1448280956337.JavaMail.zimbra@redhat.com> In-Reply-To: <87oael587p.fsf@blackfin.pond.sub.org> References: <87si401wpf.fsf@blackfin.pond.sub.org> <2083526024.12459505.1448036588653.JavaMail.zimbra@redhat.com> <564F4E68.8090903@redhat.com> <87si40sfzh.fsf@blackfin.pond.sub.org> <430569618.12530858.1448043657890.JavaMail.zimbra@redhat.com> <874mggo3yc.fsf@blackfin.pond.sub.org> <243512039.12566588.1448050691647.JavaMail.zimbra@redhat.com> <87oael587p.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: Markus Armbruster Cc: marcandre lureau , Claudio Fontana , qemu-devel@nongnu.org, Luiz Capitulino Hi ----- Original Message ----- > > >> qemu-doc documents role only with chardev. The code doesn't care. > > > > yeah, role is only really useful with a server. Another missing warning= . >=20 > I think it makes sense only when we can migrate the shared memory > contents out-of-band. Vaguely similar to block devices: either you > migrate them along (block migration), or you have to ensure they have > identical contents on the target in some other way. >=20 > Is the latter possible only with a server? The way ivshmem role works is: - master: will handle migration - peer: can't migrate It's not out-of-band, qemu handles the shared memory migration, even if the memory is owned by the server. In practice, it means you can only migrate one VM, or you migrate them all but you will migrate the shared memory N times and will have to synchronize in your guest app. I suppose iv= shmem "role" was designed to only migrate the master. Ability to migrate a pool o= f peer would be a significant new feature. I am not aware of such request. > >> This is a byzantine mess even for QEMU standards. > >>=20 > >> Questions: > >>=20 > >> * Is it okay to have an unmapped BAR? > > > > I can't say much, though I remember I did some tests and it was ok. >=20 > Did you try chardev=3D...,size=3DS, where S is larger than what the serve= r > provides? It will fall in check_shm_size(). > A guest that fails there probably works for sufficiently small S only > when it loses the race with the server. >=20 > But my question is actually whether it's okay for a PCI device to > advertize a BAR, and then not map anything there. >=20 > Should realize wait for the server providing the shared memory? >=20 > >> * We actually have two distinct device kinds: > >>=20 > >> - The basic device: shm with parameter size, or memdev > >>=20 > >> - The doorbell-capable device: chardev with parameters size, vectors= , > >> ioeventfd=3Don, msi > >>=20 > >> Common parameters: use64, role, although the latter is only document= ed > >> for the doorbell-capable device. > >>=20 >=20 > >> * Are we *sure* this is ready to become ABI? I doubt it's ABI yet, > >> because before Marc-Andr=C3=A9's massive rework, it was even worse (= *much* > >> worse), to a degree that makes me doubt anybody could use it > >> seriously. > > > > It's supposed to be the same ABI as before, with the memdev addition. >=20 > Well, it's *crap*. We shouldn't extend and known crap so it can get > used more widely, we should deprecate it in favour of something less > crappy. I think you overstate this, if it would be so bad I don't think anyone coul= d use it and it wouldn't probably be in qemu. We are mainly talking misconfigurat= ion and missing features (that people may not actually need). I think before we split things, we can address your comments with more options checking and documentation. > Here's my attempt: >=20 > 1. Split ivshmem into ivshmem-plain and ivshmem-doorbell. >=20 > Each one gets its own PCI device ID, so that guests can trivially see > whether the device got a doorbell. >=20 > Both have property use64. >=20 > ivshmem-plain additionally has property memdev. >=20 > ivshmem-doorbell additionally has chardev, size, vectors, ioeventfd, > msi. >=20 > Undecided: property role (see above). >=20 > The only non-sensical property combination is ioeventfd=3Don,msi=3Doff= , > which we cleanly reject. >=20 > Undecided: behavior before the server provides the shared memory, and > what to do when it's less than size (see above). This is the *only* > part of my proposal that may require code changes beyond > configuration. If we can't do this before the release, punt > ivshmem-doorbell to the next cycle. > 2. Drop ivshmem property memdev. >=20 > Use ivshmem-plain instead. >=20 > 3. Deprecate ivshmem. It sounds like a reasonable thing to do, but I don't think the benefit is s= o important. cheers