Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On 08/25/09 14:43, Rusty Russell wrote: On Thu, 20 Aug 2009 05:14:29 pm Gerd Hoffmann wrote: I think strings are better as numbers for identifying protocols as you can work without a central registry for the numbers then. Yep, all you need is a central registry for names :) There are schemes to do without (reverse domain names, i.e. au.com.rustcorp.* is all yours and you don't have to register). Also with names the namespace is much bigger and clashes are much less likely, so chances that it works out with everybody simply picking a sane name are much higher. cheers, Gerd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On Sat, 15 Aug 2009 01:55:32 am Anthony Liguori wrote: Gerd Hoffmann wrote: Also I still think passing a 'protocol' string for each port is a good idea, so you can stick that into a sysfs file for guests use. Or drops ports altogether and just use protocol strings... Both is silly, yes. I guess strings + HAL magic can make the /dev names sane. I don't want to see userspace trolling through sysfs to figure out what device to open. Which is why I prefer assigned numbers, which get mapped to minors. Rusty. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On 08/20/09 09:31, Rusty Russell wrote: On Sat, 15 Aug 2009 01:55:32 am Anthony Liguori wrote: Gerd Hoffmann wrote: Also I still think passing a 'protocol' string for each port is a good idea, so you can stick that into a sysfs file for guests use. Or drops ports altogether and just use protocol strings... Both is silly, yes. I guess strings + HAL magic can make the /dev names sane. I don't want to see userspace trolling through sysfs to figure out what device to open. udev can create sane /dev names (or symlinks) by checking sysfs attributes, apps just open the /dev/whatever then. Which is why I prefer assigned numbers, which get mapped to minors. ports map trivially to minors. When using protocol strings minors can simply be dynamically auto-allocated by the guest and we don't need the port numbers in the host-guest protocol any more. I think strings are better as numbers for identifying protocols as you can work without a central registry for the numbers then. cheers, Gerd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On (Thu) Aug 20 2009 [09:44:29], Gerd Hoffmann wrote: On 08/20/09 09:31, Rusty Russell wrote: On Sat, 15 Aug 2009 01:55:32 am Anthony Liguori wrote: Gerd Hoffmann wrote: Also I still think passing a 'protocol' string for each port is a good idea, so you can stick that into a sysfs file for guests use. Or drops ports altogether and just use protocol strings... Both is silly, yes. I guess strings + HAL magic can make the /dev names sane. I don't want to see userspace trolling through sysfs to figure out what device to open. udev can create sane /dev names (or symlinks) by checking sysfs attributes, apps just open the /dev/whatever then. There still will have to be some way in transferring all the strings from qemu to the guest. Could be done from the config space, but will have to be done one port at a time (config space is limited in size). Which is why I prefer assigned numbers, which get mapped to minors. ports map trivially to minors. When using protocol strings minors can simply be dynamically auto-allocated by the guest and we don't need the port numbers in the host-guest protocol any more. I think strings are better as numbers for identifying protocols as you can work without a central registry for the numbers then. I like the way assigned numbers work: it's simpler to code, needs a bitmap for all the ports that fits in nicely in the config space and udev rules / scripts can point /dev/vmch02 to /dev/console. Amit ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On (Fri) Aug 14 2009 [08:29:28], Anthony Liguori wrote: Amit Shah wrote: On (Mon) Aug 10 2009 [11:59:31], Anthony Liguori wrote: However, as I've mentioned repeatedly, the reason I won't merge virtio-serial is that it duplicates functionality with virtio-console. If the two are converged, I'm happy to merge it. I'm not opposed to having more functionality. The guest code sort-of ends up looking like this after merging virtio_console into virtio_serial. Diff is against virtio_serial in my git tree, but that should be pretty close to the last submission I made at http://patchwork.kernel.org/patch/39335/ or the tree at git://git.kernel.org/pub/scm/linux/kernel/git/amit/vs-kernel.git I've merged bits from virtio_console.c into virtio_serial.c. If needed, virtio_serial can be renamed to virtio_console. The VIRITIO_ID also needs to change to that of virtio_console's. Similar changes are needed for userspace. Since there's support for only one console as of now, I've assigned port #2 as the console port so that we hook into hvc when a port is found at that location. One issue that crops up for put_chars: a copy of the buffer to be sent has to be made as we don't wait for host to ack the buffer before we move on. The biggest loss so far is Rusty's excellent comments: they will have to be reworked and added for the whole of the new file. Is this approach acceptable? I think we want to keep virtio_console.c and definitely continue using the virtio_console id. I've now seen some more code here and to me it looks like virtioconsole is not used on any of the guests that qemu supports. The virtio_console kernel module only works with lguest and s390 currently. There is one feature and some config values supported by the kernel module but not in qemu. So it looks as if we have virtio-console merged but no one uses it. Is this right? If that's the case, I'll send patches to replace virtio-console with virtio-serial, making sure we keep the command line arg, -virtioconsole qemu char dev which will be translated to something like -virtioserial qemu char dev,port=2 or -virtioserial qemu char dev,protocol=console depending on what we finalise on. Does anyone have objections to this or pointers for me to see where virtioconsole is actually used by qemu-supported guests? I'm also open to convert the guest kernel virtio_console driver over to support the new functionality, or just let that be and have a new virtio-serial module. Rusty, what's your take on this? Amit ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On Thu, Aug 20, 2009 at 07:12:41PM +0530, Amit Shah wrote: I've now seen some more code here and to me it looks like virtioconsole is not used on any of the guests that qemu supports. The virtio_console kernel module only works with lguest and s390 currently. There is one feature and some config values supported by the kernel module but not in qemu. So it looks as if we have virtio-console merged but no one uses it. Is this right? Nope. Grab a Fedora 11 live CD, and boot with # qemu-kvm -virtioconsole stdio -cdrom Fedora-11-i686-Live.iso -m 500 Once it completes booting logs into gnome, open a terminal and run as root agetty /dev/hvc0 9600 vt100 You'll get a login prompt on the host machine now. What appears to not be working, is early kernel boot messages. eg, I ought to be able todo # qemu-kvm -virtioconsole stdio -kernel vmlinuz -initrd initrd.img \ -append console=hvc0 -m 500 and see the kernel boot messages, but this doesn't work with Fedora kernels at least. Not tried upstream, or looked to see if this is just an oversight in the Kconfig use for Fedora kernels. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On (Thu) Aug 20 2009 [15:25:09], Daniel P. Berrange wrote: On Thu, Aug 20, 2009 at 07:12:41PM +0530, Amit Shah wrote: I've now seen some more code here and to me it looks like virtioconsole is not used on any of the guests that qemu supports. The virtio_console kernel module only works with lguest and s390 currently. There is one feature and some config values supported by the kernel module but not in qemu. So it looks as if we have virtio-console merged but no one uses it. Is this right? Nope. Grab a Fedora 11 live CD, and boot with # qemu-kvm -virtioconsole stdio -cdrom Fedora-11-i686-Live.iso -m 500 Once it completes booting logs into gnome, open a terminal and run as root agetty /dev/hvc0 9600 vt100 You'll get a login prompt on the host machine now. What appears to not be working, is early kernel boot messages. eg, I ought to be able todo Oh; ok. So the console device is exposed only in the userspace; it's not used for the early boot messages and not registered early-on. That's only done for lguest and s390. # qemu-kvm -virtioconsole stdio -kernel vmlinuz -initrd initrd.img \ -append console=hvc0 -m 500 and see the kernel boot messages, but this doesn't work with Fedora kernels at least. Not tried upstream, or looked to see if this is just an oversight in the Kconfig use for Fedora kernels. Thanks, Amit ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On (Thu) Aug 20 2009 [20:08:02], Amit Shah wrote: On (Thu) Aug 20 2009 [15:25:09], Daniel P. Berrange wrote: On Thu, Aug 20, 2009 at 07:12:41PM +0530, Amit Shah wrote: I've now seen some more code here and to me it looks like virtioconsole is not used on any of the guests that qemu supports. The virtio_console kernel module only works with lguest and s390 currently. There is one feature and some config values supported by the kernel module but not in qemu. So it looks as if we have virtio-console merged but no one uses it. Is this right? Nope. Grab a Fedora 11 live CD, and boot with # qemu-kvm -virtioconsole stdio -cdrom Fedora-11-i686-Live.iso -m 500 Once it completes booting logs into gnome, open a terminal and run as root agetty /dev/hvc0 9600 vt100 You'll get a login prompt on the host machine now. What appears to not be working, is early kernel boot messages. eg, I ought to be able todo Oh; ok. So the console device is exposed only in the userspace; it's not used for the early boot messages and not registered early-on. That's only done for lguest and s390. which, by the way, doesn't change what I wrote above: since it's not used for earlyboot messages anyway it's not really used as a 'console' in its real sense and so we could just replace it with the newer version which makes it much easier for it to work with the kernel driver. Else supporting older qemu with newer kernel driver will be difficult (if not impossible). # qemu-kvm -virtioconsole stdio -kernel vmlinuz -initrd initrd.img \ -append console=hvc0 -m 500 and see the kernel boot messages, but this doesn't work with Fedora kernels at least. Not tried upstream, or looked to see if this is just an oversight in the Kconfig use for Fedora kernels. Amit ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
Amit Shah wrote: I think strings are better as numbers for identifying protocols as you can work without a central registry for the numbers then. I like the way assigned numbers work: it's simpler to code, needs a bitmap for all the ports that fits in nicely in the config space and udev rules / scripts can point /dev/vmch02 to /dev/console. How would a third party go about assigning themselves a number? For the sake of example, imagine they develop a simple service like guesttop which let's the host get a listing of guest processes. They'll have to distributed app-specific udev rule patches for every guest distro, which sounds like a lot of work. The app itself is probably a very simple C program; the hardest part of making it portable across distros would be the udev rules, which is silly. Anyway, every other device has a name or uuid these days. You can still use /dev/sda1 to refer to your boot partition, but LABEL=boot is also available if you prefer. Isn't that the ethos these days? Why not both? /dev/vmch05 if you prefer, plus symlink /dev/vmch-guesttop - /dev/vmch05 if name=guesttop was given to QEMU. If you do stay with numbers only, note that it's not like TCP/UDP port numbers because the number space is far smaller. Picking a random number that you hope nobody else uses is harder. ... Back to technical bits. If config space is tight, use a channel! Dedicate channel 0 to control, used to fetch the name (if there is one) for each number. -- Jamie ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On (Mon) Aug 10 2009 [11:59:31], Anthony Liguori wrote:
However, as I've mentioned repeatedly, the reason I won't merge
virtio-serial is that it duplicates functionality with virtio-console.
If the two are converged, I'm happy to merge it. I'm not opposed to
having more functionality.
The guest code sort-of ends up looking like this after merging
virtio_console into virtio_serial. Diff is against virtio_serial in my
git tree, but that should be pretty close to the last submission I made
at
http://patchwork.kernel.org/patch/39335/
or the tree at
git://git.kernel.org/pub/scm/linux/kernel/git/amit/vs-kernel.git
I've merged bits from virtio_console.c into virtio_serial.c. If needed,
virtio_serial can be renamed to virtio_console. The VIRITIO_ID also
needs to change to that of virtio_console's.
Similar changes are needed for userspace.
Since there's support for only one console as of now, I've assigned port
#2 as the console port so that we hook into hvc when a port is found at
that location.
One issue that crops up for put_chars: a copy of the buffer to be sent
has to be made as we don't wait for host to ack the buffer before we
move on.
The biggest loss so far is Rusty's excellent comments: they will have to
be reworked and added for the whole of the new file.
Is this approach acceptable?
diff --git a/drivers/char/Makefile b/drivers/char/Makefile
index 5e1915b..ab9c914 100644
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -53,7 +53,6 @@ obj-$(CONFIG_HVC_IRQ) += hvc_irq.o
obj-$(CONFIG_HVC_XEN) += hvc_xen.o
obj-$(CONFIG_HVC_IUCV) += hvc_iucv.o
obj-$(CONFIG_HVC_UDBG) += hvc_udbg.o
-obj-$(CONFIG_VIRTIO_CONSOLE) += virtio_console.o
obj-$(CONFIG_VIRTIO_SERIAL)+= virtio_serial.o
obj-$(CONFIG_RAW_DRIVER) += raw.o
obj-$(CONFIG_SGI_SNSC) += snsc.o snsc_event.o
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index c74dacf..f82c036 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -43,39 +43,6 @@ static struct virtio_device *vdev;
static unsigned int in_len;
static char *in, *inbuf;
-/* The operations for our console. */
-static struct hv_ops virtio_cons;
-
-/* The hvc device */
-static struct hvc_struct *hvc;
-
-/*D:310 The put_chars() callback is pretty straightforward.
- *
- * We turn the characters into a scatter-gather list, add it to the output
- * queue and then kick the Host. Then we sit here waiting for it to finish:
- * inefficient in theory, but in practice implementations will do it
- * immediately (lguest's Launcher does). */
-static int put_chars(u32 vtermno, const char *buf, int count)
-{
- struct scatterlist sg[1];
- unsigned int len;
-
- /* This is a convenient routine to initialize a single-elem sg list */
- sg_init_one(sg, buf, count);
-
- /* add_buf wants a token to identify this buffer: we hand it any
-* non-NULL pointer, since there's only ever one buffer. */
- if (out_vq-vq_ops-add_buf(out_vq, sg, 1, 0, (void *)1) == 0) {
- /* Tell Host to go! */
- out_vq-vq_ops-kick(out_vq);
- /* Chill out until it's done with the buffer. */
- while (!out_vq-vq_ops-get_buf(out_vq, len))
- cpu_relax();
- }
-
- /* We're expected to return the amount of data we wrote: all of it. */
- return count;
-}
/* Create a scatter-gather list representing our input buffer and put it in the
* queue. */
@@ -90,94 +57,7 @@ static void add_inbuf(void)
in_vq-vq_ops-kick(in_vq);
}
-/*D:350 get_chars() is the callback from the hvc_console infrastructure when
- * an interrupt is received.
- *
- * Most of the code deals with the fact that the hvc_console() infrastructure
- * only asks us for 16 bytes at a time. We keep in_offset and in_used fields
- * for partially-filled buffers. */
-static int get_chars(u32 vtermno, char *buf, int count)
-{
- /* If we don't have an input queue yet, we can't get input. */
- BUG_ON(!in_vq);
-
- /* No buffer? Try to get one. */
- if (!in_len) {
- in = in_vq-vq_ops-get_buf(in_vq, in_len);
- if (!in)
- return 0;
- }
-
- /* You want more than we have to give? Well, try wanting less! */
- if (in_len count)
- count = in_len;
-
- /* Copy across to their buffer and increment offset. */
- memcpy(buf, in, count);
- in += count;
- in_len -= count;
- /* Finished? Re-register buffer so Host will use it again. */
- if (in_len == 0)
- add_inbuf();
-
- return count;
-}
-/*:*/
-
-/*D:320 Console drivers are initialized very early so boot messages can go out,
- * so we do things slightly differently from the generic virtio initialization
- * of the net and block drivers.
- *
- * At this stage, the console is output-only. It's too early to set
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
Amit Shah wrote: On (Mon) Aug 10 2009 [11:59:31], Anthony Liguori wrote: However, as I've mentioned repeatedly, the reason I won't merge virtio-serial is that it duplicates functionality with virtio-console. If the two are converged, I'm happy to merge it. I'm not opposed to having more functionality. The guest code sort-of ends up looking like this after merging virtio_console into virtio_serial. Diff is against virtio_serial in my git tree, but that should be pretty close to the last submission I made at http://patchwork.kernel.org/patch/39335/ or the tree at git://git.kernel.org/pub/scm/linux/kernel/git/amit/vs-kernel.git I've merged bits from virtio_console.c into virtio_serial.c. If needed, virtio_serial can be renamed to virtio_console. The VIRITIO_ID also needs to change to that of virtio_console's. Similar changes are needed for userspace. Since there's support for only one console as of now, I've assigned port #2 as the console port so that we hook into hvc when a port is found at that location. One issue that crops up for put_chars: a copy of the buffer to be sent has to be made as we don't wait for host to ack the buffer before we move on. The biggest loss so far is Rusty's excellent comments: they will have to be reworked and added for the whole of the new file. Is this approach acceptable? I think we want to keep virtio_console.c and definitely continue using the virtio_console id. It looks like you are still creating character devices as opposed to tty devices. Is this just an incremental step or are you choosing to not do tty devices for a reason (as if so, what's that reason)? Regards, Anthony Liguori ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On (Fri) Aug 14 2009 [08:29:28], Anthony Liguori wrote: Amit Shah wrote: On (Mon) Aug 10 2009 [11:59:31], Anthony Liguori wrote: However, as I've mentioned repeatedly, the reason I won't merge virtio-serial is that it duplicates functionality with virtio-console. If the two are converged, I'm happy to merge it. I'm not opposed to having more functionality. The guest code sort-of ends up looking like this after merging virtio_console into virtio_serial. Diff is against virtio_serial in my git tree, but that should be pretty close to the last submission I made at http://patchwork.kernel.org/patch/39335/ or the tree at git://git.kernel.org/pub/scm/linux/kernel/git/amit/vs-kernel.git I've merged bits from virtio_console.c into virtio_serial.c. If needed, virtio_serial can be renamed to virtio_console. The VIRITIO_ID also needs to change to that of virtio_console's. Similar changes are needed for userspace. Since there's support for only one console as of now, I've assigned port #2 as the console port so that we hook into hvc when a port is found at that location. One issue that crops up for put_chars: a copy of the buffer to be sent has to be made as we don't wait for host to ack the buffer before we move on. The biggest loss so far is Rusty's excellent comments: they will have to be reworked and added for the whole of the new file. Is this approach acceptable? I think we want to keep virtio_console.c and definitely continue using the virtio_console id. It looks like you are still creating character devices as opposed to tty devices. Is this just an incremental step or are you choosing to not do tty devices for a reason (as if so, what's that reason)? Just an incremental step. In fact, I haven't yet thought about exposing a tty device and any problems that might come up. I'll get to doing that too, of course. Currently I plan to: - finish sending connect/disconnect notifications - finish merge of virtio-console and serial - look at tty Amit ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On 08/14/09 10:15, Amit Shah wrote: The guest code sort-of ends up looking like this after merging virtio_console into virtio_serial. I think it should better go the other way around: add multichannel support to virtio-concole, probably guarded by a feature flag so old host+new guest and new host+old guest combinations continue to work. Since there's support for only one console as of now, I've assigned port #2 as the console port so that we hook into hvc when a port is found at that location. Doesn't sound like this is going to be backward compatible ... Also I still think passing a 'protocol' string for each port is a good idea, so you can stick that into a sysfs file for guests use. Note it is probably easy to make virtio-console support multiple hvc lines by having one protocol for that (named 'console' for example). cheers, Gerd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
Gerd Hoffmann wrote: On 08/14/09 10:15, Amit Shah wrote: The guest code sort-of ends up looking like this after merging virtio_console into virtio_serial. I think it should better go the other way around: add multichannel support to virtio-concole, probably guarded by a feature flag so old host+new guest and new host+old guest combinations continue to work. Since there's support for only one console as of now, I've assigned port #2 as the console port so that we hook into hvc when a port is found at that location. Doesn't sound like this is going to be backward compatible ... Also I still think passing a 'protocol' string for each port is a good idea, so you can stick that into a sysfs file for guests use. Or drops ports altogether and just use protocol strings... Regards, Anthony Liguori ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
However, as I've mentioned repeatedly, the reason I won't merge virtio-serial is that it duplicates functionality with virtio-console. If the two are converged, I'm happy to merge it. I'm not opposed to having more functionality. I strongly agree. Paul ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On (Fri) Aug 07 2009 [09:14:43], Anthony Liguori wrote: Amit Shah wrote: On (Thu) Aug 06 2009 [18:37:40], Jamie Lokier wrote: Apart from dbus, hard-coded meanings of small N in /dev/vmchN are asking for trouble. It is bound to break when widely deployed and It's no different from the way major-minor numbering works on the Linux kernel: they uniquely identify a device. Bad example. Quite a lot of modern devices drivers are using dynamic major/minor numbers because they have proven to be such a pain in the butt. That's why we have more sophisticated mechanisms like udev for userspace to make use of. Let me explain how we came to this numbering: we first had support for 'naming' ports and the names were obtained by userspace programs by an ioctl. Rusty suggested to use some numbering scheme where some ports could exist at predefined locations so that we wouldn't need the naming and the ioctls around it. We'll definitely need some way to support dynamic vmchannels. Static allocation of ports is just not going to work. If we did a userspace daemon, I'd suggest using some sort of universal identifier that's easy to manage in a distributed fashion. Like a reverse fqdn. So for instance, I could have an com.ibm.my-awesome-channel and never have to worry about conflicts. Hm, we could have something like a class of ports instead of the current minor-number scheme: each port exposes what class it belongs to, like -virtioserial unix:/tmp/foo,class=stream -virtioserial unix:/tmp/bar,class=console guest/host configs don't match. It also doesn't fit comfortably when you have, say, bob and alice both logged in with desktops on separate VTs. Clashes are inevitable, as third-party apps pick N values for themselves then get distributed - unless N values can be large (/dev/vmch44324 == kernelstats...). Hm, so there can be one daemon on the guest handling all clipboard events. There's some work done already by the fast-user-switch support and that can be extended to daemons that talk over virtio-serial. You could have one daemon that manages all vmchannel sessions. It can then expose channels to apps via whatever mechanism is best. It could use unix domain sockets, sys v ipc, whatever floats your boat. And, you can build this daemon today using the existing vmchannel over TCP/IP. You could also make it support serial devices. We could also introduce a custom usb device and use libusb. libusb is portable to Windows and Linux. There are some other problems with usb too: It's not transparent to users. Any hotplug event could alert users and that's not desired. It's a system-only thing and should also remain that way. Amit ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
Gerd Hoffmann wrote: There are some other problems with usb too: It's not transparent to users. Any hotplug event could alert users and that's not desired. It's a system-only thing and should also remain that way. I think virtio-serial is the better way to handle vmchannel. Unlike usb virtio is designed to work nicely in a virtual environment. But vmchannel-over-usbserial should be easy too though in case some guests lacks virtio backports or something. I think you're missing my fundamental point. Don't use the kernel as the guest interface. Introduce a userspace daemon that exposes a domain socket. Then we can have a proper protocol that uses reverse fqdns for identification. We can do the backend over TCP/IP, usb, standard serial, etc. Regards, Anthony Liguori ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On 08/10/09 15:02, Anthony Liguori wrote: I think you're missing my fundamental point. Don't use the kernel as the guest interface. Introduce a userspace daemon that exposes a domain socket. Then we can have a proper protocol that uses reverse fqdns for identification. We need nothing but (a) bidirectional byte streams and (b) name tags for them. Do we really want design a daemon and a protocol for such a simple thing? Especially as requiring a daemon for that adds a few problems you don't have without them. Access control for example: For device nodes you can just use standard unix permissions and acls. You can easily do stuff like adding the logged in desktop user to the /dev/vmchannel/org/qemu/clipboard acl using existing solutions. With a daemon you have to hop through a number of loops to archive the same. Can't we simply have guest apps open /dev/vmchannel/$protocol ? cheers, Gerd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
Amit Shah wrote: Let me explain how we came to this numbering: we first had support for 'naming' ports and the names were obtained by userspace programs by an ioctl. Rusty suggested to use some numbering scheme where some ports could exist at predefined locations so that we wouldn't need the naming and the ioctls around it. Fortunately, if you implement the naming scheme in userspace you get the best of both worlds ;-) Hm, so there can be one daemon on the guest handling all clipboard events. There's some work done already by the fast-user-switch support and that can be extended to daemons that talk over virtio-serial. You could have one daemon that manages all vmchannel sessions. It can then expose channels to apps via whatever mechanism is best. It could use unix domain sockets, sys v ipc, whatever floats your boat. And, you can build this daemon today using the existing vmchannel over TCP/IP. You could also make it support serial devices. We could also introduce a custom usb device and use libusb. libusb is portable to Windows and Linux. There are some other problems with usb too: It's not transparent to users. Any hotplug event could alert users and that's not desired. I don't think this is true in practice. Our goal is not to circumvent an OS's policy decisions either. It's a system-only thing and should also remain that way. I don't buy this argument at all. If you exposed a new usb device that no OS had a kernel driver, and you had a daemon running that watched for insertions of that device, what OS would that not work transparently on? I think my fundamental argument boils down to two points. 1) we should not require new guest drivers unless we absolutely have to 2) we should always do things in userspace unless we absolutely have to do things in the kernel. Adding new kernel drivers breaks support for enterprise Linux distros. Adding a userspace daemon does not. Windows device drivers require signing which is very difficult to do. There's a huge practical advantage in not requiring guest drivers. Regards, Anthony Liguori Amit ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On 08/10/09 16:20, Anthony Liguori wrote: Gerd Hoffmann wrote: Do we really want design a daemon and a protocol for such a simple thing? Yes, because we also need (c) the ability to write cross platform software that targets vmchannel. So having a library interface is going to be extremely desirable. You don't need a daemon for that though. Also, see the previous discussion about security. How do you sanely delegate /dev/vmchannel/org/qemu/clipboard to the current Xorg user? pam_console (I think that is the name of the beast). Or is it handled by hal these days? The piece of software which does the very same thing already for sound and other devices. Especially as requiring a daemon for that adds a few problems you don't have without them. Access control for example: For device nodes you can just use standard unix permissions and acls. But how do you set those permissions in the first place? See above. There are other devices which need that too. There are existing solutions for this problem. You can easily do stuff like adding the logged in desktop user to the /dev/vmchannel/org/qemu/clipboard acl using existing solutions. With a daemon you have to hop through a number of loops to archive the same. Can't we simply have guest apps open /dev/vmchannel/$protocol ? /dev interfaces are only simple to kernel developers :-) Besides, why do something that can be clearly done in userspace within the kernel? Ok, lets rip out the in-kernel ioapic code then. It can (and has been) done in userspace. It just increases the possibility of kernel bugs. The daemon increases the possibility of userspace bugs. Seriously: Attaching a name tag to virtio-serial devices and have them exposed via sysfs is probably *much* less code than a vmchannel daemon. Also multiplexing over one device introduces a number of problems you have to take care of on both sides (qemu+daemon) of the connection. For example: When the communication stalls in one protocol the others should keep on going of course. With one device per protocol and thus one virtqueue per protocol the problem doesn't exist in the first place. You can have a /var/run/vmchannel/$protocol.sock unix domain socket and it has all the same properties that you describe. It also Just Works with standard tools like socat. bash: socat: command not found If we really want vmchannel to be used by application developers, then we really need a libvmchannel. We need a sane solution developed and merged and not a new idea each week. cheers, Gerd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On 08/10/09 16:27, Anthony Liguori wrote: I think my fundamental argument boils down to two points. 1) we should not require new guest drivers unless we absolutely have to Allow guest drivers is fine though I guess? 2) we should always do things in userspace unless we absolutely have to do things in the kernel. Wrong. There are often good reasons to do stuff in kernel, even if you can do it in userspace too. Adding new kernel drivers breaks support for enterprise Linux distros. Adding a userspace daemon does not. Windows device drivers require signing which is very difficult to do. There's a huge practical advantage in not requiring guest drivers. Ok, so the virtio-serial + usbserial combo should work well then I think. If you have guest drivers you'll go the virtio-serial route. If you don't have guest drivers you can go the usbserial route, either via /dev/ttyUSB or via libusb. We can also have a libvmchannel as abstraction layer on top of this. cheers, Gerd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
Gerd Hoffmann wrote: Ok, lets rip out the in-kernel ioapic code then. It can (and has been) done in userspace. The justification is performance although that's not really true anymore post TPR optimization. But FWIW, I opposed both the in-kernel apic and the in-kernel pit when they were introduced. If nothing else, I'm at least consistent :-) The daemon increases the possibility of userspace bugs. How? Seriously: Attaching a name tag to virtio-serial devices and have them exposed via sysfs is probably *much* less code than a vmchannel daemon. I strongly doubt that. If we really want vmchannel to be used by application developers, then we really need a libvmchannel. We need a sane solution developed and merged and not a new idea each week. There is nothing sane about vmchannel. It's just an attempt to bypass QEMU which is going to introduce all sorts of complexities wrt migration, guest compatibility, etc. However, as I've mentioned repeatedly, the reason I won't merge virtio-serial is that it duplicates functionality with virtio-console. If the two are converged, I'm happy to merge it. I'm not opposed to having more functionality. I think it's the wrong solution for the use-case, and I always have, but that's independent of my willingness to merge it. Regards, Anthony Liguori ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
Anthony Liguori wrote: There is nothing sane about vmchannel. It's just an attempt to bypass QEMU which is going to introduce all sorts of complexities wrt migration, guest compatibility, etc. However, as I've mentioned repeatedly, the reason I won't merge virtio-serial is that it duplicates functionality with virtio-console. If the two are converged, I'm happy to merge it. I'm not opposed to having more functionality. NB: the userspace interface for these devices should be a tty, not a new character device. If you want to add a new bustype for these devices, and then have an entry in sysfs that had some sort of identification string, that's perfectly acceptable. Also note though that this is exactly what usb-serial is today. /sys/bus/usbserial contains all the usb serial devices and you can get a vendor id/device id to uniquely identify the device type. Using virtio vs. usb has it's advantage but the userspace interface model should be roughly equivalent. Regards, Anthony Liguori ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On Mon, 10 Aug 2009 07:17:54 pm Gerd Hoffmann wrote: On 08/10/09 08:55, Amit Shah wrote: Bad example. Quite a lot of modern devices drivers are using dynamic major/minor numbers because they have proven to be such a pain in the butt. That's why we have more sophisticated mechanisms like udev for userspace to make use of. Let me explain how we came to this numbering: we first had support for 'naming' ports and the names were obtained by userspace programs by an ioctl. Rusty suggested to use some numbering scheme where some ports could exist at predefined locations so that we wouldn't need the naming and the ioctls around it. I think the naming is very important. I disagree. If you can hand out names, you can hand out numbers. Whether the guest chooses to put that number in sysfs or make it a minor, I don't care. Rusty. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
Rusty Russell wrote: On Mon, 10 Aug 2009 07:17:54 pm Gerd Hoffmann wrote: On 08/10/09 08:55, Amit Shah wrote: Bad example. Quite a lot of modern devices drivers are using dynamic major/minor numbers because they have proven to be such a pain in the butt. That's why we have more sophisticated mechanisms like udev for userspace to make use of. Let me explain how we came to this numbering: we first had support for 'naming' ports and the names were obtained by userspace programs by an ioctl. Rusty suggested to use some numbering scheme where some ports could exist at predefined locations so that we wouldn't need the naming and the ioctls around it. I think the naming is very important. I disagree. If you can hand out names, you can hand out numbers. The problem with handing out names is that there has to be someone to hand things out. And even if you have a good hander-outer, development is difficult in a distributed environment because you may have folks using your code before you've gotten an official hand-out. A better discovery mechanism is based on something that piggy backs on another authority. For instance, reverse fully qualified domains work well. uuid's tend to work pretty well too although it's not perfect. In general, even just open strings can work out okay given that people are responsible in how they name things. Regards, Anthony Liguori ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On (Thu) Aug 06 2009 [18:37:40], Jamie Lokier wrote:
Amit Shah wrote:
On (Thu) Aug 06 2009 [08:58:01], Anthony Liguori wrote:
Amit Shah wrote:
On (Thu) Aug 06 2009 [08:29:40], Anthony Liguori wrote:
Amit Shah wrote:
Sure; but there's been no resistance from anyone from including the
virtio-serial device driver so maybe we don't need to discuss that.
There certainly is from me. The userspace interface is not
reasonable for guest applications to use.
One example that would readily come to mind is dbus. A daemon running on
the guest that reads data off the port and interacts with the desktop by
appropriate dbus commands. All that's needed is a stream of bytes and
virtio-serial provides just that.
dbus runs as an unprivileged user, how does dbus know which
virtio-serial port to open and who sets the permissions on that port?
The permission part can be handled by package maintainers and sysadmins
via udev policies.
So all data destined for dbus consumption gets to a daemon and that
daemon then sends it over to dbus.
virtio-serial is nice, easy, simple and versatile. We like that; it
should stay that way.
dbus isn't a good match for this.
dbus is not intended for communication between hosts, by design.
Oh; I don't mean to say dbus on the host will communicate directly with
dbus on the guest via virtio-serial. I'm just saying there'll be some
daemon on the guest and if there's a request for, say, updating guest
clipboard with some contents, it can be passed on to dbus on the guest.
It depends on per-app configuration files in
/etc/dbus/{session,system}.d/, which are expected to match the
installed services.
For this, the guest's files in /etc/dbus/ would have to match the QEMU
host host services in detail. dbus doesn't have a good mechanism for
copying with version skew between both of them, because normally
everything resides on the same machine and the config and service are
updated at the same time. This is hard to guarantee with a VM.
Right. Not proposing this at all.
Apart from dbus, hard-coded meanings of small N in /dev/vmchN are
asking for trouble. It is bound to break when widely deployed and
It's no different from the way major-minor numbering works on the Linux
kernel: they uniquely identify a device. Or the way tcp port number
works. In the same way, /dev/vmchN will uniquely identify some function
over a port. You idea of introducing a symlink to /dev/clipboard is a
good one and it takes one udev rule to generate that link.
guest/host configs don't match. It also doesn't fit comfortably when
you have, say, bob and alice both logged in with desktops on separate
VTs. Clashes are inevitable, as third-party apps pick N values for
themselves then get distributed - unless N values can be large
(/dev/vmch44324 == kernelstats...).
Hm, so there can be one daemon on the guest handling all clipboard
events. There's some work done already by the fast-user-switch support
and that can be extended to daemons that talk over virtio-serial.
Sysadmins shouldn't have to hand-configure each app, and shouldn't
have to repair clashes in defaults. Just Work is better.
No; they shouldn't need to.
virtio-serial is nice. The only ugly part is _finding_ the right
/dev/vmchN.
Fortunately, _any_ out-of-band id string or id number makes it perfect.
An option to specify PCI vendor/product ids in the QEMU host
configuration is good enough.
An option to specify one or more id strings is nicer.
Finally, Anthony hit on an interesting idea with USB. Emulating USB
sucks. But USB's _descriptors_ are quite effective, and the USB basic
protocol is quite reasonable too.
Descriptors are just a binary blob in a particular format, which
describe a device and also say what it supports, and what standard
interfaces can be used with it too. Bluetooth is similar; they might
even use the same byte format, I'm not sure.
And doing something similar is akin to populating some files in /sys.
All the code for parsing USB descriptors is already present in guest
kernels, and the code for making appropriate device nodes and
launching apps is already in udev. libusb also allows devices to be
used without a kernel driver, and is cross-platform. There are plenty
of examples of creating USB descriptors in QEMU, and may be the code
can be reused.
The only down side of USB is that emulating it sucks :-) That's mainly
due to the host controllers, and the way interrupts use polling.
So here's a couple of ideas:
- virtio-usb, using virtio instead of a hardware USB host
controller. That would provide all the features of USB
naturally, like hotplug, device binding, access from userspace,
but with high performance, low overhead, and no interrupt polling.
I wonder how that's any different or less complex that virtio-serial.
Essentially the idea is
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On (Wed) Aug 05 2009 [18:57:13], Jamie Lokier wrote: Anthony Liguori wrote: Richard W.M. Jones wrote: Have you considered using a usb serial device? Something attractive about it is that a productid/vendorid can be specified which means that you can use that as a method of enumerating devices. Hot add/remove is supported automagically. The same applies to PCI: productid/vendorid (and subids); PCI hotplug is possible though not as native as USB. Here's another idea: Many devices these days have a serial number or id string. E.g. USB storage, ATA drives, media cards, etc. Linux these days creates alias device nodes which include the id string in the device name. E.g. /dev/disks/by-id/ata-FUJITSU_MHV2100BH_NWAQT662615H So in addition to (or instead of) /dev/vmch0, /dev/vmch1 etc., Linux guests could easily generate: /dev/vmchannel/by-role/clipboard-0 /dev/vmchannel/by-role/gueststats-0 /dev/vmchannel/by-role/vmmanager-0 That's interesting; worth a thought. When we actually have all the parties together (libvirt, libguestfs, qemu) to decide which ports need to act as which transports, we'll be able to add this. It's not necessary to do this at the beginning. All that is needed is to provide enough id information that will appear in /sys/..., so that that a udev policy for naming devices can be created at some later date. True. Amit ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On (Wed) Aug 05 2009 [13:00:57], Anthony Liguori wrote: Jamie Lokier wrote: Anthony Liguori wrote: Richard W.M. Jones wrote: Have you considered using a usb serial device? Something attractive about it is that a productid/vendorid can be specified which means that you can use that as a method of enumerating devices. Hot add/remove is supported automagically. The same applies to PCI: productid/vendorid (and subids); PCI hotplug is possible though not as native as USB. What's nice about USB is that HID specifies quite a few functional generic devices that can be extended to increase functionality. This means you can implement a more sophisticated usb device that satisfies the serial interface, provide a special more featureful driver for Linux, and just use normal serial for Windows. The downside is that USB emulation stinks. And the virtio code is pretty simple and self-contained. I don't see why we'd restrict us more to use something else. Here's another idea: Many devices these days have a serial number or id string. E.g. USB storage, ATA drives, media cards, etc. Linux these days creates alias device nodes which include the id string in the device name. E.g. /dev/disks/by-id/ata-FUJITSU_MHV2100BH_NWAQT662615H So in addition to (or instead of) /dev/vmch0, /dev/vmch1 etc., Linux guests could easily generate: /dev/vmchannel/by-role/clipboard-0 /dev/vmchannel/by-role/gueststats-0 /dev/vmchannel/by-role/vmmanager-0 It's not necessary to do this at the beginning. All that is needed is to provide enough id information that will appear in /sys/..., so that that a udev policy for naming devices can be created at some later date. Well my thinking is that the clipboard device actually becomes a USB serial device. It's easy to enumerate and detect via the existing Linux infrastructure. Plus usb drivers can be implemented in userspace which is a nice plus (cross platform too via libusb). Sure; but there's been no resistance from anyone from including the virtio-serial device driver so maybe we don't need to discuss that. Amit ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
Amit Shah wrote: Sure; but there's been no resistance from anyone from including the virtio-serial device driver so maybe we don't need to discuss that. There certainly is from me. The userspace interface is not reasonable for guest applications to use. Regards, Anthony Liguori Amit ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On (Thu) Aug 06 2009 [08:29:40], Anthony Liguori wrote: Amit Shah wrote: Sure; but there's been no resistance from anyone from including the virtio-serial device driver so maybe we don't need to discuss that. There certainly is from me. The userspace interface is not reasonable for guest applications to use. One example that would readily come to mind is dbus. A daemon running on the guest that reads data off the port and interacts with the desktop by appropriate dbus commands. All that's needed is a stream of bytes and virtio-serial provides just that. Any more complexity could easily be handled in userspace. Amit ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On (Thu) Aug 06 2009 [08:58:01], Anthony Liguori wrote: Amit Shah wrote: On (Thu) Aug 06 2009 [08:29:40], Anthony Liguori wrote: Amit Shah wrote: Sure; but there's been no resistance from anyone from including the virtio-serial device driver so maybe we don't need to discuss that. There certainly is from me. The userspace interface is not reasonable for guest applications to use. One example that would readily come to mind is dbus. A daemon running on the guest that reads data off the port and interacts with the desktop by appropriate dbus commands. All that's needed is a stream of bytes and virtio-serial provides just that. dbus runs as an unprivileged user, how does dbus know which virtio-serial port to open and who sets the permissions on that port? The permission part can be handled by package maintainers and sysadmins via udev policies. So all data destined for dbus consumption gets to a daemon and that daemon then sends it over to dbus. Amit ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
Amit Shah wrote:
On (Thu) Aug 06 2009 [08:58:01], Anthony Liguori wrote:
Amit Shah wrote:
On (Thu) Aug 06 2009 [08:29:40], Anthony Liguori wrote:
Amit Shah wrote:
Sure; but there's been no resistance from anyone from including the
virtio-serial device driver so maybe we don't need to discuss that.
There certainly is from me. The userspace interface is not
reasonable for guest applications to use.
One example that would readily come to mind is dbus. A daemon running on
the guest that reads data off the port and interacts with the desktop by
appropriate dbus commands. All that's needed is a stream of bytes and
virtio-serial provides just that.
dbus runs as an unprivileged user, how does dbus know which
virtio-serial port to open and who sets the permissions on that port?
The permission part can be handled by package maintainers and sysadmins
via udev policies.
So all data destined for dbus consumption gets to a daemon and that
daemon then sends it over to dbus.
virtio-serial is nice, easy, simple and versatile. We like that; it
should stay that way.
dbus isn't a good match for this.
dbus is not intended for communication between hosts, by design.
It depends on per-app configuration files in
/etc/dbus/{session,system}.d/, which are expected to match the
installed services.
For this, the guest's files in /etc/dbus/ would have to match the QEMU
host host services in detail. dbus doesn't have a good mechanism for
copying with version skew between both of them, because normally
everything resides on the same machine and the config and service are
updated at the same time. This is hard to guarantee with a VM.
Apart from dbus, hard-coded meanings of small N in /dev/vmchN are
asking for trouble. It is bound to break when widely deployed and
guest/host configs don't match. It also doesn't fit comfortably when
you have, say, bob and alice both logged in with desktops on separate
VTs. Clashes are inevitable, as third-party apps pick N values for
themselves then get distributed - unless N values can be large
(/dev/vmch44324 == kernelstats...).
Sysadmins shouldn't have to hand-configure each app, and shouldn't
have to repair clashes in defaults. Just Work is better.
virtio-serial is nice. The only ugly part is _finding_ the right
/dev/vmchN.
Fortunately, _any_ out-of-band id string or id number makes it perfect.
An option to specify PCI vendor/product ids in the QEMU host
configuration is good enough.
An option to specify one or more id strings is nicer.
Finally, Anthony hit on an interesting idea with USB. Emulating USB
sucks. But USB's _descriptors_ are quite effective, and the USB basic
protocol is quite reasonable too.
Descriptors are just a binary blob in a particular format, which
describe a device and also say what it supports, and what standard
interfaces can be used with it too. Bluetooth is similar; they might
even use the same byte format, I'm not sure.
All the code for parsing USB descriptors is already present in guest
kernels, and the code for making appropriate device nodes and
launching apps is already in udev. libusb also allows devices to be
used without a kernel driver, and is cross-platform. There are plenty
of examples of creating USB descriptors in QEMU, and may be the code
can be reused.
The only down side of USB is that emulating it sucks :-) That's mainly
due to the host controllers, and the way interrupts use polling.
So here's a couple of ideas:
- virtio-usb, using virtio instead of a hardware USB host
controller. That would provide all the features of USB
naturally, like hotplug, device binding, access from userspace,
but with high performance, low overhead, and no interrupt polling.
You'd even have the option of cross-platform guest apps, as well
as working on all Linux versions, by emulating a host controller
when the guest doesn't have virtio-usb.
As a bonus, existing USB support would be accelerated.
- virtio-serial providing a binary id blob, whose format is the
same as USB descriptors. Reuse the guest's USB parsing and
binding to find and identify, but the actual device functionality
would just be a byte pipe.
That might be simple, as all it involves is a blob passed to the
guest from QEMU. QEMU would build the id blob, maybe reusing
existing USB code, and the guest would parse the blob as it
already does for USB devices, with udev creating devices as it
already does.
-- Jamie
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
Anthony Liguori wrote: Richard W.M. Jones wrote: Have you considered using a usb serial device? Something attractive about it is that a productid/vendorid can be specified which means that you can use that as a method of enumerating devices. Hot add/remove is supported automagically. The same applies to PCI: productid/vendorid (and subids); PCI hotplug is possible though not as native as USB. Here's another idea: Many devices these days have a serial number or id string. E.g. USB storage, ATA drives, media cards, etc. Linux these days creates alias device nodes which include the id string in the device name. E.g. /dev/disks/by-id/ata-FUJITSU_MHV2100BH_NWAQT662615H So in addition to (or instead of) /dev/vmch0, /dev/vmch1 etc., Linux guests could easily generate: /dev/vmchannel/by-role/clipboard-0 /dev/vmchannel/by-role/gueststats-0 /dev/vmchannel/by-role/vmmanager-0 It's not necessary to do this at the beginning. All that is needed is to provide enough id information that will appear in /sys/..., so that that a udev policy for naming devices can be created at some later date. -- Jamie ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
Gleb Natapov wrote: On Wed, Jul 29, 2009 at 01:14:18PM +0530, Amit Shah wrote: But why do we want to limit the device to only one port? It's not too complex supporting additional ones. As I see it qemu and the kernel should provide the basic abstraction for the userspace to go do its job. Why create unnecessary barriers? I agree. If userspace wants it may use only one channel and demultiplex messages by itself, but we shouldn't force it to. Also one of the requirements for virtio-serial is to have connect disconnect notifications. It is not possible with demultiplexing in the userspace. I agree too, for all those reasons. However it would be useful if the devices provided a simpler way to be found by guest applications than /dev/vmch0, vmch1, vmch2... On Linux udev provides a sane way to find devices according to roles, subtypes, serial numbers, whatever you want, if the appropriate id codes are available from the devices and put into /sys/* by the kernel driver. That would make the devices much more useful to independent applications, imho. -- Jamie ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On Mon, Aug 03, 2009 at 02:57:01PM -0500, Anthony Liguori wrote: Richard W.M. Jones wrote: On Mon, Jul 27, 2009 at 06:44:28PM -0500, Anthony Liguori wrote: It really suggests that you need _one_ vmchannel that's exposed to userspace with a single userspace daemon that consumes it. ... or a more flexible API. I don't like having fixed /dev/vmch* devices either. Have you considered using a usb serial device? Something attractive about it is that a productid/vendorid can be specified which means that you can use that as a method of enumerating devices. Hot add/remove is supported automagically. [ Meant to reply to this two days ago :-( ] We're using -net channel ^W guestfwd in libguestfs now. Apart from the problem with using the new syntax, which I hope to get around to resolving some day, it performs quite well. The userspace API is somewhat annoying. Hot add/remove isn't a concern for us right now, nor is migration. Since we can throw up new qemu-based appliances in a few seconds. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
Richard W.M. Jones wrote: On Mon, Jul 27, 2009 at 06:44:28PM -0500, Anthony Liguori wrote: It really suggests that you need _one_ vmchannel that's exposed to userspace with a single userspace daemon that consumes it. ... or a more flexible API. I don't like having fixed /dev/vmch* devices either. Have you considered using a usb serial device? Something attractive about it is that a productid/vendorid can be specified which means that you can use that as a method of enumerating devices. Hot add/remove is supported automagically. Regards, Anthony Liguori ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On (Tue) Jul 28 2009 [08:42:32], Anthony Liguori wrote: Amit Shah wrote: Right; use virtio just as the transport and all the interesting activity happens in userspaces. That was the basis with which I started. I can imagine dbus doing the copy/paste, lock screen, etc. actions. However for libguestfs, dbus isn't an option and they already have some predefined agents for each port. So libguestfs is an example for a multi-port usecase for virtio-serial. Or don't use dbus and use something that libguestfs is able to embed. The fact that libguestfs doesn't want dbus in the guest is not an argument for using a higher level kernel interface especially one that doesn't meet the requirements of the interface. But why do we want to limit the device to only one port? It's not too complex supporting additional ones. As I see it qemu and the kernel should provide the basic abstraction for the userspace to go do its job. Why create unnecessary barriers? Amit ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On Wed, Jul 29, 2009 at 01:14:18PM +0530, Amit Shah wrote: On (Tue) Jul 28 2009 [08:42:32], Anthony Liguori wrote: Amit Shah wrote: Right; use virtio just as the transport and all the interesting activity happens in userspaces. That was the basis with which I started. I can imagine dbus doing the copy/paste, lock screen, etc. actions. However for libguestfs, dbus isn't an option and they already have some predefined agents for each port. So libguestfs is an example for a multi-port usecase for virtio-serial. Or don't use dbus and use something that libguestfs is able to embed. The fact that libguestfs doesn't want dbus in the guest is not an argument for using a higher level kernel interface especially one that doesn't meet the requirements of the interface. But why do we want to limit the device to only one port? It's not too complex supporting additional ones. As I see it qemu and the kernel should provide the basic abstraction for the userspace to go do its job. Why create unnecessary barriers? I agree. If userspace wants it may use only one channel and demultiplex messages by itself, but we shouldn't force it to. Also one of the requirements for virtio-serial is to have connect disconnect notifications. It is not possible with demultiplexing in the userspace. -- Gleb. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On (Mon) Jul 27 2009 [18:44:28], Anthony Liguori wrote: Jamie Lokier wrote: With multiple X servers, there can be more than one currently logged in user. Same with multiple text consoles - that's more familiar. Which one owns /dev/vmch3? For a VMM, copy/paste should work with whatever user has the active X session that's controlling the physical display. Yes, it could get complicated if we supported multiple video cards, but fortunately we don't :-) I really think you need to have a copy/paste daemon that allows multiple X sessions to connect to it and then that daemon can somehow determine who is the active session. This is part of the reason I've been pushing for a concrete example. All the signs here point to a privileged daemon that delegates to multiple users. I think just about any use-case will have a similar model. It really suggests that you need _one_ vmchannel that's exposed to userspace with a single userspace daemon that consumes it. You want the flexibility of a userspace daemon in determining how you multiplex and do security. I don't think it's something you want to bake into the userspace/kernel interface. Right; use virtio just as the transport and all the interesting activity happens in userspaces. That was the basis with which I started. I can imagine dbus doing the copy/paste, lock screen, etc. actions. However for libguestfs, dbus isn't an option and they already have some predefined agents for each port. So libguestfs is an example for a multi-port usecase for virtio-serial. And if you have a single daemon that serves vmchannel sessions, that daemon can make it transparent whether the session is going over /dev/ttyS0, a network device, /dev/hvc1, etc. or /dev/vmch0. it doesn't matter. All minimal virtio devices will look the same. Pop buffers, populate them, push them, etc. Amit ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
Amit Shah wrote: Right; use virtio just as the transport and all the interesting activity happens in userspaces. That was the basis with which I started. I can imagine dbus doing the copy/paste, lock screen, etc. actions. However for libguestfs, dbus isn't an option and they already have some predefined agents for each port. So libguestfs is an example for a multi-port usecase for virtio-serial. Or don't use dbus and use something that libguestfs is able to embed. The fact that libguestfs doesn't want dbus in the guest is not an argument for using a higher level kernel interface especially one that doesn't meet the requirements of the interface. Regards, Anthony Liguori ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On Mon, Jul 27, 2009 at 06:44:28PM -0500, Anthony Liguori wrote: It really suggests that you need _one_ vmchannel that's exposed to userspace with a single userspace daemon that consumes it. ... or a more flexible API. I don't like having fixed /dev/vmch* devices either. A long time ago (on a mailing list not so far away) there was a much better userspace API proposed, which had a separate AF_VMCHANNEL address family. That API works much more like TCP sockets, except without requiring network devices: https://lists.linux-foundation.org/pipermail/virtualization/2008-December/012383.html Note: even better if it allows multiple channels with the same name to be created on demand from the guest, which the API would allow, although not the implementation above. That would allow the fast-user-switching / multi-X-server case to work well, and be useful if we parallelize libguestfs. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
Richard W.M. Jones wrote: On Mon, Jul 27, 2009 at 06:44:28PM -0500, Anthony Liguori wrote: It really suggests that you need _one_ vmchannel that's exposed to userspace with a single userspace daemon that consumes it. ... or a more flexible API. I don't like having fixed /dev/vmch* devices either. Indeed. A long time ago (on a mailing list not so far away) there was a much better userspace API proposed, which had a separate AF_VMCHANNEL address family. That API works much more like TCP sockets, except without requiring network devices: Dave Miller nacked that approach with a sledgehammer instead preferring that we just use standard TCP/IP which is what led to the current implementation using slirp. A userspace daemon with unix domain sockets could give a similar solution. Regards, Anthony Liguori ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On Tue, Jul 28, 2009 at 09:48:00AM -0500, Anthony Liguori wrote: Richard W.M. Jones wrote: On Mon, Jul 27, 2009 at 06:44:28PM -0500, Anthony Liguori wrote: It really suggests that you need _one_ vmchannel that's exposed to userspace with a single userspace daemon that consumes it. ... or a more flexible API. I don't like having fixed /dev/vmch* devices either. Indeed. A long time ago (on a mailing list not so far away) there was a much better userspace API proposed, which had a separate AF_VMCHANNEL address family. That API works much more like TCP sockets, except without requiring network devices: Dave Miller nacked that approach with a sledgehammer instead preferring that we just use standard TCP/IP which is what led to the current implementation using slirp. I'm aware of that - I just don't think it was a good choice. [BTW the qemu-devel mailing list seems to be bouncing messages] Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
Richard W.M. Jones wrote: On Tue, Jul 28, 2009 at 09:48:00AM -0500, Anthony Liguori wrote: Dave Miller nacked that approach with a sledgehammer instead preferring that we just use standard TCP/IP which is what led to the current implementation using slirp. I'm aware of that - I just don't think it was a good choice. [BTW the qemu-devel mailing list seems to be bouncing messages] I know. I've reported it to the Savannah admins and am helping them track it down. Rich. Regards, Anthony Liguori ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
On Mon, Jul 27, 2009 at 03:22:54PM -0500, Anthony Liguori wrote: Amit Shah wrote: Hello all, This are the latest version of the patches. Lots of things have changed since the last submission. A few of which I remember: - VNC copy / paste works* (* conditions apply) - client vnc copies get propagated to guest port 3 (/dev/vmch3) - guest writes to port 3 (/dev/vmch3) go straight to client's clipboard Why 3? Where's the guest application that drives the copy/paste? I expect the first problem you'll run into is that copy/paste daemon has to run as an unprivileged user but /dev/vmch3 is going to be owned by root. You could set udev rules for /dev/vmch3 but that's pretty terrible IMHO. I don't think that's not too bad, for example, with fast-user-switching between multiple X servers and/or text consoles, there's already support code that deals with chown'ing things like /dev/snd/* devices to match the active console session. Doing the same with the /dev/vmch3 device so that it is only ever accessible to the current logged in user actually fits in to that scheme quite well. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
Daniel P. Berrange wrote: I expect the first problem you'll run into is that copy/paste daemon has to run as an unprivileged user but /dev/vmch3 is going to be owned by root. You could set udev rules for /dev/vmch3 but that's pretty terrible IMHO. I don't think that's not too bad, for example, with fast-user-switching between multiple X servers and/or text consoles, there's already support code that deals with chown'ing things like /dev/snd/* devices to match the active console session. Doing the same with the /dev/vmch3 device so that it is only ever accessible to the current logged in user actually fits in to that scheme quite well. With multiple X servers, there can be more than one currently logged in user. Same with multiple text consoles - that's more familiar. Which one owns /dev/vmch3? -- Jamie ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
