Re: [Qemu-devel] [PATCH 3/6] virtio-console: Add a virtio-console bus, support for multiple ports

[Amit Shah]

On (Thu) Oct 01 2009 [10:38:18], Gerd Hoffmann wrote:
>   Hi,
>
>>> Sure.  I think there is a misunderstanding here.  I meant only the
>>> "buffer messages when unconnected" thing.  Reassembling the messages in
>>> the core and forward only complete messages to the ports is fine.
>>
>> OK; so in that case, passing a ptr to the buffer and its length is fine,
>> no?
>
> Will work.  We need some clear rules for buffer memory though.  Possible  
> ways to deal with it:
>
>   (1) core owns the buffer.  If the port driver wants to keep the
>       content it has to memcpy() it to own memory.
>   (2) have_data() callback transfers buffer ownership from core to
>       the port driver.  It is the port drivers job to free the memory
>       when it doesn't need it any more.
>   (3) reference-count the buffers.
>
> For (1) + (2) both buffer struct and ptr+len will work.
>
> For (3) ptr+len wouldn't work though, you'll need some struct containing  
> ptr, len, refcount and helper functions to get/put buffers.

Yeah; Currently it's only (1). But I'm now thinking of doing (2). One
concern Yaniv raised was a port driver may not consume all the data
right away, so it's better to let the port do the buffer management.

>>> If you do '-device virtio-console-pci -device virtio-port' (i.e. no
>>> console) and boot a old guest kernel which expects a (single) console
>>> being there, what will happen?
>>
>> OK -- I get what you're saying now. However, I don't see any problem
>> here. If there is no virtioconsole specified to qemu, there's no reason
>> to expect a console in the guest. That was the case in the past and is
>> the case now as well. The difference is earlier, when probe() in the
>> guest was called, it definitely meant the existence of a console. Now,
>> even if probe() is invoked, it doesn't mean a console was found. But
>> this hardly is a concern.
>
> True for new guest kernels, they simply don't create a hvc.
> Question is what *old* guest kernels will do in that case.

If the guest kernel doesn't support the new virtio feature
VIRTIO_F_MULTIPORT, then we disable all this functionality and only
allow one port. That one port has to be the console port. I've tested
this combination, btw.

However, it's possible that some of the checks got lost in the latest
rework and that port 0 isn't actually a console port. I'll go through
init code again to ensure this. Thanks for explaining the scenario!

                Amit