qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 5/8] virtio-serial-bus: Add support for bufferin


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 5/8] virtio-serial-bus: Add support for buffering guest output, throttling guests
Date: Tue, 12 Jan 2010 09:55:41 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

On 01/12/2010 09:49 AM, Amit Shah wrote:
On (Tue) Jan 12 2010 [09:46:55], Anthony Liguori wrote:
On 01/12/2010 09:13 AM, Amit Shah wrote:
On (Tue) Jan 12 2010 [09:00:52], Anthony Liguori wrote:

On 01/12/2010 01:16 AM, Amit Shah wrote:

BTW I don't really want this too, I can get rid of it if everyone agrees
we won't support clipboard writes>    4k over vnc or if there's a better
idea.


Why bother trying to preserve message boundaries?   I think that's the
fundamental question.

For the vnc clipboard copy-paste case, I explained that in the couple of
mails before in this thread.

It didn't make sense to me.  I think the assumption has to be that the
client can send corrupt data and the host has to handle it.
You mean if the guest kernel sends the wrong flags? Or doesn't set the
flags? Can you explain what scenario you're talking about?

It's very likely that you'll have to implement some sort of protocol on top of virtio-serial. It won't always just be simple strings.

If you have a simple datagram protocol, that contains two ints and a string, it's going to have to be encoded like <int a><int b><int len><char data[len]>. You need to validate that len fits within the boundaries and deal with len being less than the boundary.

If you've got a command protocol where the you send the guest something and then expect a response, you have to deal with the fact that the guest may never respond. Having well defined message boundaries does not help the general problem and it only helps in the most trivial cases.

Basically, it boils down to a lot of complexity for something that isn't going to be helpful in most circumstances.

Regards,

Anthony Liguori

                Amit





reply via email to

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