Keir Fraser wrote: > > On 22 Mar 2006, at 16:00, Anthony Liguori wrote: > >> This has always seemed a bit wrong to me and makes a number of things >> kind of awkward (like a virtual video driver). >> >> It would seem better me to treat this driver as what it really is, a >> virtual serial device. It adds a little bit of additional work to >> the userspace tools (they just have to make sure to pass >> console=ttyS0) but it seems worth it. > > That already works pretty much (userspace tools have to pass > xencons=ttyS as well as console=ttyS0). >> We could also solve the tty[0-9] problem by implementing a proper >> console driver that could use multiple virtual serial devices if we >> wanted to go that route. > > Yes, that could live alongside this driver. This is going to come up in the next release if we try to merge the framebuffer stuff. >> Another option would be to just emulate a serial driver. The console >> driver isn't really performance critical. It seems to me that it's a >> bit unnecessary to even bother paravirtualizing the console device >> when it's so easy to emulate. > > Easy except that Xen can't implement the 'console backend', or at > least not easily. The console bits need to end up in management > virtual machine's user space. We'd have to do something skanky like > the current HVM qemu model. We could make an exception for console devices and just have a small buffer in the hypervisor for console input/output (similar to the emergency console). The biggest advantage to doing this IMHO is that it makes guest OS's a bit easier to port. The console already is treated as an exception since it is setup in start_info (instead of through XenBus) so this is not that awful I think. Regards, Anthony Liguori > -- Keir >
