From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:57352)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1bKCT5-0004kn-Hn
	for qemu-devel@nongnu.org; Mon, 04 Jul 2016 18:35:56 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1bKCT0-0006mo-HR
	for qemu-devel@nongnu.org; Mon, 04 Jul 2016 18:35:54 -0400
Received: from mx1.redhat.com ([209.132.183.28]:45653)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1bKCT0-0006mi-Bd
	for qemu-devel@nongnu.org; Mon, 04 Jul 2016 18:35:50 -0400
Date: Tue, 5 Jul 2016 01:35:45 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
Message-ID: <20160705013310-mutt-send-email-mst@redhat.com>
References: <1466503372-28334-1-git-send-email-marcandre.lureau@redhat.com>
	<1466503372-28334-9-git-send-email-marcandre.lureau@redhat.com>
	<20160623072740-mutt-send-email-mst@redhat.com>
	<842458024.1343130.1466673244073.JavaMail.zimbra@redhat.com>
	<20160623200309-mutt-send-email-mst@redhat.com>
	<CAJ+F1CJDQqmhSbPbAWRnpD6yAa-8kYFBSxOZ-VNuDFYY8Fst8A@mail.gmail.com>
	<20160704184717-mutt-send-email-mst@redhat.com>
	<CAJ+F1CKXLu7ziNo6i7+-p17wFXOGEa+d-AyusQmngVnR-A168w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <CAJ+F1CKXLu7ziNo6i7+-p17wFXOGEa+d-AyusQmngVnR-A168w@mail.gmail.com>
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH 08/24] vhost-user: return a read error
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: =?iso-8859-1?Q?Marc-Andr=E9?= Lureau <marcandre.lureau@gmail.com>
Cc: yuanhan liu <yuanhan.liu@linux.intel.com>, Victor Kaplansky <victork@redhat.com>, QEMU <qemu-devel@nongnu.org>, jonshin@cisco.com, Tetsuya Mukawa <mukawa@igel.co.jp>

On Mon, Jul 04, 2016 at 11:56:56PM +0200, Marc-Andr=E9 Lureau wrote:
> Hi
>=20
> On Mon, Jul 4, 2016 at 5:47 PM, Michael S. Tsirkin <mst@redhat.com> wro=
te:
> > Why does vhost_user_set_log_base need to return error?
> > If backend is not there to handle this message,
> > then it is not changing memory so it's ok to ignore the error.
>=20
> How do you know it's not changing the memory?

either it closed socket intentionally or it exited
and kernel cleaned up.

> Furthermore, if the migration happened, it's because backend claim
> VHOST_F_LOG_ALL, thus it should really not fail

I don't see why - could you explain pls?

> > Same logic applies to many other messages.
>=20
> Pretty much all messages, the error can't be ignored, or operations
> will just fail silentely randomly. I don't understand why vhost-user
> io error can be ignored. Also it's quite inconsistent the way the code
> is today, vhost_user_write() returns an error that is mostly ignored,
> while vhost_user_read() is checked. Why having an error later when you
> can report it earlier? I fail to understand the rationale of this
> error handling.

It's historical.  the way I see it, most errors due to disconnect
can be ignored except
maybe for the initial feature negotiation which is needed
so we know what to tell guest.

Errors due to e.g. buffer being full should cause an assert
as it's an internal qemu error.


>=20
> --=20
> Marc-Andr=E9 Lureau