From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NUUbG-0001vt-PM for qemu-devel@nongnu.org; Mon, 11 Jan 2010 19:27:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NUUbB-0001u4-Mm for qemu-devel@nongnu.org; Mon, 11 Jan 2010 19:27:10 -0500 Received: from [199.232.76.173] (port=44192 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NUUbB-0001u1-Gf for qemu-devel@nongnu.org; Mon, 11 Jan 2010 19:27:05 -0500 Received: from mail-qy0-f189.google.com ([209.85.221.189]:53526) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NUUbB-00070l-4e for qemu-devel@nongnu.org; Mon, 11 Jan 2010 19:27:05 -0500 Received: by qyk27 with SMTP id 27so9706484qyk.20 for ; Mon, 11 Jan 2010 16:27:04 -0800 (PST) Message-ID: <4B4BC1D5.2060105@codemonkey.ws> Date: Mon, 11 Jan 2010 18:27:01 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 5/8] virtio-serial-bus: Add support for buffering guest output, throttling guests References: <1262849506-27132-6-git-send-email-amit.shah@redhat.com> <20100108011231.GA5011@shareable.org> <20100108050351.GB8999@amit-x200.redhat.com> <20100108133503.GA19328@shareable.org> <20100111083443.GA6061@amit-x200.redhat.com> <20100111104553.GA4746@shareable.org> <20100111110410.GA13658@amit-x200.redhat.com> <20100111233356.GB30714@shareable.org> In-Reply-To: <20100111233356.GB30714@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Amit Shah , qemu-devel@nongnu.org On 01/11/2010 05:33 PM, Jamie Lokier wrote: > Amit Shah wrote: > >>> Are you talking about a VNC protocol command between qemu's VNC server >>> and the user's VNC client, or a private protocol between the guest and >>> qemu's VNC server? >>> >> What happens is: >> >> 1. Guest puts something on its clipboard >> 2. An agent on the guest gets notified of new clipboard contents >> 3. This agent sends over the entire clipboard contents to qemu via >> virtio-serial >> 4. virtio-serial sends off this data to the virtio-serial-vnc code >> 5. ServerCutText message from the vnc backend is sent to the vnc client >> 6. vnc client's clipboard gets updated >> 7. You can see guest's clipboard contents in your client's clipboard. >> >> I'm talking about steps 3, 4, 5 here. >> > Ok. Let's not worry about 5; it doesn't seem relevant, only that the > guest clipboad is sent to the host somehow. > > >>> You have already told it the total length to expect. There is no >>> ambiguity about where it ends. >>> >> Where does the total length come from? It has to come from the guest. >> Otherwise, the vnc code will not know if a byte stream contains two >> separate clipboard entries or just one huge clipboard entry. >> > I see. So it's a *really simple* protocol where the clipboard entry > is sent by the guest agent with a single write() without any framing bytes? > > >> Earlier, I used to send the length of one write as issued by a guest to >> qemu. I just changed that to send a START and END flag so that I don't >> have to send the length. >> > Why not just have the guest agent send a 4-byte header which is the > integer length of the clipboard blob to follow? > > I.e. instead of > > int guest_send_clipboard(const char *data, size_t length) > { > return write_full(virtio_fd, data, length); > } > > do this: > > int guest_send_clipboard(const char *data, size_t length) > { > u32 encoded_length = cpu_to_be32(length); > int err = write_full(virtio_serial_fd,&encoded_length, > sizeof(encoded_length)); > if (err == 0) > err = write_full(virtio_serial_fd, data, length); > return err; > } > > >> If this doesn't explain it, then I think we're not understanding each >> other here. >> > It does explain it very well, thanks. I think you're misguided about > the solution :-) > > What confused me was you mentioned the VNC ServerCutText command > having to receive the whole data in one go. ServerCutText isn't > really relevant to this, and clearly is encoded with VNC protocol > framing. If it was RDP or the SDL client instead of VNC, it would be > something else. All that matters is getting the clipboard blob from > guest to qemu in one piece, right? > > Having the guest agent send a few framing bytes seems very simple, and > would have the added bonus that the same guest agent protocol would > work on a "real" emulated serial port, guest->host TCP, etc. where > virtio-serial isn't available in the guest OS (e.g. older kernels). > > I really can't see any merit in making virtio-serial not be a serial > port, being instead like a unix datagram socket, to support a specific > user of virtio-serial when a trivial 4-byte header in the guest agent > code would be easier for that user anyway. > > If it did that, I think the name virtio-serial would have to change to > virtio-datagram, becuase it wouldn't behave like a serial port any > more. It would also be less useful for things that _do_ want > something like a pipe/serial port. But why bother? > I agree wrt a streaming protocol verses a datagram protocol. The core argument IMHO is that the userspace interface is a file descriptor. Most programmers are used to assuming that boundaries aren't preserved in read/write calls. Regards, Anthony Liguori > -- Jamie > > >