[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Insane virtio-serial semantics

From: Anthony Liguori
Subject: Re: [Qemu-devel] Insane virtio-serial semantics
Date: Wed, 07 Dec 2011 07:49:50 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

On 12/07/2011 02:21 AM, Markus Armbruster wrote:
Anthony Liguori<address@hidden>  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 
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.


Anthony Liguori


reply via email to

[Prev in Thread] Current Thread [Next in Thread]