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

[Amit Shah]

On (Tue) Jan 12 2010 [09:55:41], Anthony Liguori wrote:
> 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.

Yes, virtio-serial is just meant to be a transport agnostic of whatever
data or protocols that ride over it.

> 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.

I don't know why you're saying virtio-serial-bus does (or needs to) do
anything of this.

                Amit