From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:33237)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mlureau@redhat.com>) id 1Zzs8T-0003VI-Hc
	for qemu-devel@nongnu.org; Fri, 20 Nov 2015 15:18:22 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mlureau@redhat.com>) id 1Zzs8O-0003Fz-Ho
	for qemu-devel@nongnu.org; Fri, 20 Nov 2015 15:18:21 -0500
Received: from mx5-phx2.redhat.com ([209.132.183.37]:34656)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mlureau@redhat.com>) id 1Zzs8O-0003Fc-Av
	for qemu-devel@nongnu.org; Fri, 20 Nov 2015 15:18:16 -0500
Date: Fri, 20 Nov 2015 15:18:11 -0500 (EST)
From: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau <mlureau@redhat.com>
Message-ID: <243512039.12566588.1448050691647.JavaMail.zimbra@redhat.com>
In-Reply-To: <874mggo3yc.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>
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: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Markus Armbruster <armbru@redhat.com>
Cc: marcandre lureau <marcandre.lureau@redhat.com>, Claudio Fontana <claudio.fontana@huawei.com>, qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>

Hi

----- Original Message -----
> >> Hash ivshmem been used in anger?  If yes, how?
>=20
> Still the question to answer.

I don't expect users to read this ML everyday (anybody actually). Personall=
y, I have no clue how widespread ivshmem usage is.

> Besides the usual PCI properties, we have:
>=20
>     ivshmem.chardev=3Dstr (ID of a chardev to use as a backend)
>     ivshmem.size=3Dstr
>     ivshmem.vectors=3Duint32
>     ivshmem.ioeventfd=3Dbool (on/off)
>     ivshmem.msi=3Dbool (on/off)
>     ivshmem.shm=3Dstr
>     ivshmem.role=3Dstr
>     ivshmem.memdev=3Dlink<memory-backend>
>     ivshmem.use64=3Duint32
>=20
> Exactly one of chardev, shm, memdev must be given.  qemu-doc.info claims
> you can omit all three, but that's a bug.

interesting, I guess the doc must be updated

> vectors, ioeventfd and msi make sense only with chardev.  The code
> appears to silently ignore them unless chardev is given.  Except it
> still rejects ioeventfd=3Don,msi=3Doff.  I wouldn't bet on nonsensical
> combinations to actually work.

I haven't tried all combinations, to me it's not a bug if an argument is si=
lently ignored, but we are missing a warning.

> qemu-doc documents role only with chardev.  The code doesn't care.

yeah, role is only really useful with a server. Another missing warning.

> size makes sense only with shm and chardev.  If you specify it with
> memdev, it's ignored with a warning.

Ah! it's probably fine then?

> With shm, we first try to create the shared memory object with the
> specified size, and if that fails, we try to open it.  The specified
> size must not be larger than the shared memory object then.
>=20
> With chardev, we receive the shared memory object from the server.
> Until we get it, BAR isn't mapped.  If the specified size is larger, the
> BAR remains unmapped.

yep

> use64 sets PCI_BASE_ADDRESS_SPACE_MEMORY.  Not documented in qemu-doc.

I don't think all properties are documented, are they? Gerd added this in c=
08ba66f with pretty good commit message that we could adapt to add in docum=
entation.

> 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.

> * 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 documented
>   for the doorbell-capable device.
>=20
>   Why is this a single device model?

No idea, but I agree it would make sense to have two different devices.

>   It's not even obvious to me how the guest is supposed to figure out
>   which kind it has.

I don't think it can easily: I can imagine sending a doorbell to yourself, =
but that wouldn't be really reliable either.

> * shm appears to be the same as memdev, just less flexible.  Why does it
>   exist?

It was there before.
=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 (*mu=
ch*
>   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.