|
From: | Gerd Hoffmann |
Subject: | Re: [Qemu-devel] [PATCH 3/6] virtio-console: Add a virtio-console bus, support for multiple ports |
Date: | Thu, 01 Oct 2009 10:38:18 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Lightning/1.0pre Thunderbird/3.0b3 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |