From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41178) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RYHsq-0005fy-AW for qemu-devel@nongnu.org; Wed, 07 Dec 2011 08:50:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RYHsi-0001AI-UJ for qemu-devel@nongnu.org; Wed, 07 Dec 2011 08:50:04 -0500 Received: from mail-ey0-f173.google.com ([209.85.215.173]:56203) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RYHsi-00019x-OX for qemu-devel@nongnu.org; Wed, 07 Dec 2011 08:49:56 -0500 Received: by eaai10 with SMTP id i10so535190eaa.4 for ; Wed, 07 Dec 2011 05:49:55 -0800 (PST) Message-ID: <4EDF6EFE.3040303@codemonkey.ws> Date: Wed, 07 Dec 2011 07:49:50 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <20111205222208.31271.65662.stgit@ginnungagap.bsc.es> <20111205222312.31271.66303.stgit@ginnungagap.bsc.es> <4EDE7343.3010305@codemonkey.ws> <87ty5d1gfw.fsf@ginnungagap.bsc.es> <4EDE98BA.9070902@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] Insane virtio-serial semantics List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Blue Swirl , qemu-devel@nongnu.org, Michael Roth , Zhi Yong Wu , amit.shah@redhat.com, Cam Macdonell , =?UTF-8?B?TGx1?= =?UTF-8?B?w61zIFZpbGFub3Zh?= On 12/07/2011 02:21 AM, Markus Armbruster wrote: > Anthony Liguori writes: > >> On 12/06/2011 04:30 PM, Lluís Vilanova wrote: >>> Anthony Liguori writes: >>> >>>> I really worry about us introducing so many of these one-off paravirtual devices. >>>> I would much prefer that you look at doing this as an extension to the ivshmem >>>> device as it already has this sort of scope. You should be able to do this by >>>> just extending the size of bar 1 and using a well known guest id. >>> >>> I did in fact look at ivshmem some time ago, and it's true that both use the >>> same mechanisms; but each device has a completely different purpose. To me it >>> just seems that extending the control BAR in ivshmem to call the user-provided >>> backdoor callbacks is just conflating two completely separate devices into a >>> single one. Besides, I think that the qemu-side of the backdoor is simple enough >>> to avoid being a maintenance burden. >> >> They have the same purpose (which are both vague TBH). The only >> reason I'm sympathetic to this device is that virtio-serial has such >> insane semantics. > > Could you summarize what's wrong? Is it fixable? I don't think so as it's part of the userspace ABI now. Mike, please help me make sure I get this all right. A normal file/socket has the following guest semantics: 1) When a disconnect occurs, you will receive a return of '0' or -EPIPE depending on the platform. The fd is now unusable and you must close/reopen. 2) You can setup SIGIO/SIGPIPE to fire off whenever a file descriptor becomes readable/writable. virtio serial has the following semantics: 1) When a disconnect occurs, if you read() you will receive an -EPIPE. 2) However, if a reconnect occurs before you issue your read(), the read will complete with no indication that a disconnect occurred. 3) This makes it impossible to determine whether a disconnect has occurred which makes it very hard to reset your protocol stream. To deal with this, virtio-serial can issue a SIGIO signal upon disconnect. 4) Signals are asynchronous, so a reconnect may have occurred by the time you get the SIGIO signal. It's unclear that you can do anything useful with this. So besides overloading the meaning of SIGIO, there's really no way to figure out in the guest when a reconnect has occurred. To deal with this in qemu-ga, we actually only allow 7-bit data transfers and use the 8th bit as an in-band message to tell the guest that a reset has occurred. Regards, Anthony Liguori > > [...] >