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

[Alexander Graf]

On 25.01.2013, at 20:04, Blue Swirl wrote:

> On Thu, Jan 24, 2013 at 6:10 AM, Anup Patel <anup.patel at 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.

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.


Alex