Re: [Qemu-devel] [PATCH 5/8] virtio-serial-bus: Add support for buffering guest output, throttling guests

[Amit Shah]

On (Mon) Jan 11 2010 [10:45:53], Jamie Lokier wrote:
> Amit Shah wrote:
> > On (Fri) Jan 08 2010 [13:35:03], Jamie Lokier wrote:
> > > Since VNC is clearly designed to work over TCP, and is written by
> > > people who know this, I'm wondering why you think it needs to be
> > > different for virtio-serial.
> > 
> > For vnc putting stuff from a guest clipboard into vnc client clipboard
> > using the ServerCutText command, the entire buffer has to be provided
> > after sending the command and the 'length' values.
> 
> 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.

> > In this case, if the data from guest arrives in multiple packets, we
> > really don't want to call into the write function multiple times. A
> > single clipboard entry has to be created in the client with the entire
> > contents, so a single write operation has to be invoked.
> 
> Same question again: *Why do you think the VNC server (in qemu) needs to
> see the entire clipboard in a aingle write from the guest?*
> 
> 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.

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.

If this doesn't explain it, then I think we're not understanding each
other here.

                Amit