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

[Gerd Hoffmann <kraxel@redhat.com>]

   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.

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

cheers,
   Gerd