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

[Blue Swirl]

On Sun, Jan 27, 2013 at 8:20 AM, Gleb Natapov <gleb at redhat.com> wrote:
> 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 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.
>>
> Same with irq chip. Implementing PV irqchip today is going backwards.

I'm not sure this should be the conclusion. Obviously throwing more
hardware at virtualization makes it faster and the x86 host will
probably also benefit from faster interrupt handling as a side
benefit, so emulating the PIC etc. makes sense for now and also in
short term (some years from now).

But long term, if you could direct the hardware design efforts of
major companies and standardization bodies to any direction, is fast
emulation of 30 year old technology what would create the fastest
architecture in the future? For example, maybe the PIC+LAPIC should be
replaced in long term by something that can vector the interrupts to
different VCPUs directly, each at different privilege levels?

>
>> 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.

HW acceleration of Xen would just need faster IPC, but that has
probably reached max performance ages ago.

The legacy driver benefit is a good point, though more so for short term.

>
> --
>                         Gleb.