[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communic
From: |
Amit Shah |
Subject: |
Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication |
Date: |
Tue, 28 Jul 2009 16:06:24 +0530 |
User-agent: |
Mutt/1.5.19 (2009-01-05) |
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
- [Qemu-devel] virtio-serial: An interface for host-guest communication, Amit Shah, 2009/07/27
- [Qemu-devel] Re: virtio-serial: An interface for host-guest communication, Anthony Liguori, 2009/07/27
- Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication, Daniel P. Berrange, 2009/07/27
- Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication, Anthony Liguori, 2009/07/27
- Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication, Jamie Lokier, 2009/07/27
- Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication, Anthony Liguori, 2009/07/27
- Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication,
Amit Shah <=
- Message not available
- Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication, Amit Shah, 2009/07/29
- Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication, Gleb Natapov, 2009/07/29
- Message not available
- Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication, Anthony Liguori, 2009/07/28
- Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication, Richard W.M. Jones, 2009/07/28
- Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication, Anthony Liguori, 2009/07/28