[Qemu-devel] [kvmarm] [RFC] Virtio-desktop: Virtio-based virtual desktop

[gleb@redhat.com (Gleb Natapov)]

On Fri, Jan 25, 2013 at 08:31:54PM +0100, Alexander Graf wrote:
> 
> On 25.01.2013, at 20:04, Blue Swirl wrote:
> 
> > On Thu, Jan 24, 2013 at 6:10 AM, Anup Patel <anup.patel@linaro.org> wrote:
> >> Hi All,
> >> 
> >> How about having a generic Virtio-based machine for emulating a virtual
> >> desktop ?
> > 
> > I have also thought about this, current virtio design is not very
> > clean. On the downside, pure no-legacy approach might not work well if
> > you want the host to give control of a host device to guest (VFIO like
> > pass through using IOMMUs).
> > 
> >> I know folks have already thought about this and probably also tried
> >> something or other on this front but, it will be good to know the downsides.
> >> 
> >> Virtio-desktop can be a separate specification describing a virtual desktop.
> >> Of-course we cannot avoid few architecture dependent virtual devices in but
> >> the Virtio-desktop specification will try to keep minimum possible
> >> architecture dependent devices.
> >> 
> >> As per our thoughts, a Virtio-desktop will have two kinds of devices:
> >> 1. Architecture dependent devices: This devices will be emulated in-kernel
> >> by architecture specific code of KVM or Xen or Some other hypervisor.
> >>   a) Virtualized CPU
> >>   b) Virtualized PIC (i.e. in-kernel architecture specific emulation of
> >> irqchip)
> >>   c) Virtualized Timer (i.e. in-kernel architecture specific emulation of
> >> timer chip)
> > 
> > I think reusing PIC and timer design is not the most optimal. What a
> > PV aware OS really wants is to wake up because of an external event or
> > at some specific point of time (or after a specific delay) and easy
> > way to manage the VM clock without timer tick counting. With a
> > tickless approach, it would need the timer events as rarely as
> > possible.
> > 
> > Perhaps a better approach would be to introduce a way for the guest to
> > subscribe to a list of external events (including time), which would
> > be fed to it via something like reverse hypercall (or just use legacy
> > interrupts). Preferably it should be possible to pass any events
> > through a stack of guests to the end consumer guest and even
> > applications in a guest.
> 
> This approach falls apart once hardware vendors implement timer interrupts inside a guest context (which Intel and IIUC ARM are doing). At that point, it's actually more efficient to do real timer calls to real hardware.
> 
Same with irq chip. Implementing PV irqchip today is going backwards.

> PV is bad. We only do it when we have to. Not doing PV where we don't have to is exactly the reason KVM is superior to Xen.
> 
Exactly. Implementing PV for something that does not require PV (for
performance reasons mostly) is trading tested guest code, to untested,
and unwritten, one.

--
			Gleb.