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

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

[Stefan Hajnoczi]

On Thu, Jan 24, 2013 at 11:40:24AM +0530, Anup Patel wrote:
> IMHO, If we have something like Virtio-desktop specification then all
> possible guest OSes can have support for it and different hypervisor can
> emulate it without worrying about guest support.

At this point x86 virtualization is mature and working with a mix of
emulated x86 architecture pieces and virtio devices for
performance-critical or open-ended functionality that we want to be able
to extend.

ARM is getting KVM and virtio-mmio support.  It will be in a similar
position soon.

Virtio guest drivers have not been implemented widely.  The Linux and
Windows efforts are driven by the folks who were behind virtio from the
start, but Solaris, FreeBSD, and others didn't really jump on the virtio
bandwagon.

Given this landscape, what is the advantage of doing a virtio-desktop?
It will still need to fall back on ARM or x86 which is already being
virtualized and emulated.

Depending on how you see it we either have virtio-desktop already or,
if not, I think the experience with virtio adoption suggests other
hypervisors and guest OSes will not trip over themselves to implement
virtio-desktop.

What's the advantage over virtualizating an existing ARM or x86 platform
and using virtio devices where appropriate?

Stefan

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

[Alexander Graf]

On 24.01.2013, at 10:25, Stefan Hajnoczi wrote:

> On Thu, Jan 24, 2013 at 11:40:24AM +0530, Anup Patel wrote:
>> IMHO, If we have something like Virtio-desktop specification then all
>> possible guest OSes can have support for it and different hypervisor can
>> emulate it without worrying about guest support.
> 
> At this point x86 virtualization is mature and working with a mix of
> emulated x86 architecture pieces and virtio devices for
> performance-critical or open-ended functionality that we want to be able
> to extend.
> 
> ARM is getting KVM and virtio-mmio support.  It will be in a similar
> position soon.
> 
> Virtio guest drivers have not been implemented widely.  The Linux and
> Windows efforts are driven by the folks who were behind virtio from the
> start, but Solaris, FreeBSD, and others didn't really jump on the virtio
> bandwagon.
> 
> Given this landscape, what is the advantage of doing a virtio-desktop?
> It will still need to fall back on ARM or x86 which is already being
> virtualized and emulated.
> 
> Depending on how you see it we either have virtio-desktop already or,
> if not, I think the experience with virtio adoption suggests other
> hypervisors and guest OSes will not trip over themselves to implement
> virtio-desktop.
> 
> What's the advantage over virtualizating an existing ARM or x86 platform
> and using virtio devices where appropriate?

You don't get changing hardware for changing CPUs. I don't think it makes sense to do a cross-arch virtio-desktop machine type. Different architectures simply have different needs.

But check out the QEMU e500 machine. We have a fully device tree based machine type in the kernel. QEMU drives it by generating a device tree for devices it actually exposes on the fly.

The big advantage we have here is that

  1) We don't have to emulate all hardware real hardware emulates
  2) We're not restricted to emulate what real hardware emulates. PCI on ARM anyone?
  3) Different CPU types can live on the same machine. This is something that x86 is doing already. When you get a SoC, guests are usually guaranteed a core <-> device correlation though.

So overall, having a PV machine makes sense. Having the same common PV machine standardized across different architectures does not make sense.


Alex

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

[Peter Maydell]

On 24 January 2013 14:38, Alexander Graf <agraf@suse.de> wrote:
> But check out the QEMU e500 machine. We have a fully device tree
> based machine type in the kernel. QEMU drives it by generating a
> device tree for devices it actually exposes on the fly.

The ARM equivalent for that would be mach-virt, I think
(I forget what the status is but no doubt somebody will
remind me :-))

> The big advantage we have here is that
>
>   1) We don't have to emulate all hardware real hardware emulates
>   2) We're not restricted to emulate what real hardware emulates. PCI on ARM anyone?

...do we have an ARM PCI controller of any working kind in
the kernel? versatilepb's PCI controller doesn't count as
it is utterly broken :-)

-- PMM

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

[Alexander Graf]

On 24.01.2013, at 15:42, Peter Maydell wrote:

> On 24 January 2013 14:38, Alexander Graf <agraf@suse.de> wrote:
>> But check out the QEMU e500 machine. We have a fully device tree
>> based machine type in the kernel. QEMU drives it by generating a
>> device tree for devices it actually exposes on the fly.
> 
> The ARM equivalent for that would be mach-virt, I think
> (I forget what the status is but no doubt somebody will
> remind me :-))
> 
>> The big advantage we have here is that
>> 
>>  1) We don't have to emulate all hardware real hardware emulates
>>  2) We're not restricted to emulate what real hardware emulates. PCI on ARM anyone?
> 
> ...do we have an ARM PCI controller of any working kind in
> the kernel? versatilepb's PCI controller doesn't count as
> it is utterly broken :-)

Don't the Marvell chips have PCI? And Tegra? I'm sure there have to be some SoCs with PCI :).


Alex

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

[Stefan Hajnoczi]

On Thu, Jan 24, 2013 at 2:08 PM, Anup Patel <anup.patel@linaro.org> wrote:
> On 24 January 2013 14:55, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>>
>> On Thu, Jan 24, 2013 at 11:40:24AM +0530, Anup Patel wrote:
>> > IMHO, If we have something like Virtio-desktop specification then all
>> > possible guest OSes can have support for it and different hypervisor can
>> > emulate it without worrying about guest support.
>>
>> At this point x86 virtualization is mature and working with a mix of
>> emulated x86 architecture pieces and virtio devices for
>> performance-critical or open-ended functionality that we want to be able
>> to extend.
>>
>> ARM is getting KVM and virtio-mmio support.  It will be in a similar
>> position soon.
>>
>> Virtio guest drivers have not been implemented widely.  The Linux and
>> Windows efforts are driven by the folks who were behind virtio from the
>> start, but Solaris, FreeBSD, and others didn't really jump on the virtio
>> bandwagon.
>
> [Anup] I think other OSes will be motivated to added Virtio drivers if there
> exists some think like Virtio-desktop specification that is being emulated
> by
> many hypervisors.

Absolutely, if most hypervisors implement it then guests will also
implement it.  But this is exactly what I tried to describe in the
previous email:

Yes, virtio has the potential to be implemented by many hypervisors.
The specification is out there and existing open source
implementations are out there.

But the leading x86 hypervisors (kvm, xen, vmware, hyperv) implement
their own paravirt I/O approaches.  This may be due to historical
reasons but virtio has been around long enough for any of the other
big hypervisors to implement it if they wanted to.

Code sharing or a unified standard isn't sufficient motivation when
there are other factors like ability to change device spec to achieve
better performance, compatibility with existing guests, ability to add
new features, certified device drivers, etc.

The incentives need to be favorable for hypervisors to wed themselves
to a standardized paravirt device - simply adding more virtio devices
doesn't change today's incentives, so you cannot expect hypervisor
vendors to act differently from how they have in the past.

Stefan

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

[Blue Swirl]

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.

> 2. Architecture independent devices: This are Virtio-based devices which are
> usually required by a desktop virtual machine.
>    a) Virtio-blk (storage)
>       - Already available
>    b) Virtio-net (network)
>      - Already available
>    c) Virtio-fb (display)
>      - It seems some work has been already done for Virtio frame buffer but
> I did not find drivers/fb/virtio-fb.c in latest kernel
>        (http://thread.gmane.org/gmane.comp.emulators.kvm.devel/42720)
>      - Is Virtio-fb work still in-progress ??
>    d) Virtio-input (keyboard/mouse/multi-touch)
>      - Currently not available
>      - It will provide keyboard input events
>      - It will provide mouse input events
>      - It will provide multi-touch input events
>    e) Virtio-power (reset/shutdown/enumeration)
>      - It can provides info about the entire virtual machine including CPU,
> PIC, Timer, available Virtio devices, etc.
>      - It can also provide CPU and Virtio-device hot-plugging
>      - Its primary purpose would be to provide reset and shutdown of CPU and
> Virtio devices.
>      - There will be only one instance of this device and its location will
> be fixed for each architecture.

d) and e) would be also covered by the PV event device. Perhaps also a) and b).

I'm not sure how c) would be different from X11 (the original network
protocol using version, not Wayland).

>
> The Virtio-desktop specification may also describe a recommended memory map
> of for each architecture.

Memory management (ballooning and page faults) could also use the
event device. The use of events could also avoid memory to memory
copies (zero copy) by letting the host manage the buffer memory.

>
> Right now, only missing devices seems to be Virtio-fb, Virtio-input, and
> Virtio-power, which some of us are willing to take-up.
>
> IMHO, If we have something like Virtio-desktop specification then all
> possible guest OSes can have support for it and different hypervisor can
> emulate it without worrying about guest support.
>
> Best Regards,
> Anup

[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@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

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

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

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

[Blue Swirl]

On Sun, Jan 27, 2013 at 8:20 AM, Gleb Natapov <gleb@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@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.

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

[Gleb Natapov]

On Sun, Jan 27, 2013 at 10:12:20AM +0000, Blue Swirl wrote:
> On Sun, Jan 27, 2013 at 8:20 AM, Gleb Natapov <gleb@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@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).
Moder OSes, i.e those that have a non zero chance to get virtio-desktop
support, do not use PIC on x86 after bootup, so there is not performance
gains in replacing it with something PV and I hope you do not propose
that.  You probably think about using PV in place of LAPIC which,
besides have to be written and debugged,  will be slower on modern x86 HW
since mode x86 HW accelerates LAPIC emulation. AFAIK arm also has irq
chip virtualization support in HW.

> 
> 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?
>
What prevents you from doing it today with LAPIC/MSIX? PIC/IOAPIC are
legacy and not used for anything performance sensitive.  And do you truly
believe that HW vendors will abandon current HW in favor of your design?

--
			Gleb.

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

[Anthony Liguori]

Anup Patel <anup.patel@linaro.org> writes:

> Hi All,
>
> How about having a generic Virtio-based machine for emulating a virtual
> desktop ?
>
> 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.

There's a lot of reasons why a pure PV machine type is a bad idea.  Lots
of people have enumerated them in this thread.

But let me mention some things that I think we don't have covered today
with PV:

 - Graphics.  Yes, I know QXL exists but it's (a) dependent on PCI (b)
   lacks the ability to gracefully degrade making it hopelessly tied to
   spice.

 - Input.  PS/2 mouse provides relative input which sucks in guests.
   For absolute input, we have VMMouse which is x86-specific, USB
   tablets (which are expensive to emulate) or the spice mouse which is
   intimately tied to the full Spice stack.

 - Guest interaction.  Copy/paste, drag and drop, etc.  In theory this
   is covered in spice agents but it's all again hopelessly tied to
   Spice which makes it non-portable.

So there's good work todo but it's almost certainly in working with the
Spice community to try to make what they already have more accessible to
non-x86 architectures.

Regards,

Anthony Liguori

>
> 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)
> 2. Architecture independent devices: This are Virtio-based devices which
> are usually required by a desktop virtual machine.
>    a) Virtio-blk (storage)
>       - Already available
>    b) Virtio-net (network)
>      - Already available
>    c) Virtio-fb (display)
>      - It seems some work has been already done for Virtio frame buffer but
> I did not find drivers/fb/virtio-fb.c in latest kernel
>        (http://thread.gmane.org/gmane.comp.emulators.kvm.devel/42720)
>      - Is Virtio-fb work still in-progress ??
>    d) Virtio-input (keyboard/mouse/multi-touch)
>      - Currently not available
>      - It will provide keyboard input events
>      - It will provide mouse input events
>      - It will provide multi-touch input events
>    e) Virtio-power (reset/shutdown/enumeration)
>      - It can provides info about the entire virtual machine including CPU,
> PIC, Timer, available Virtio devices, etc.
>      - It can also provide CPU and Virtio-device hot-plugging
>      - Its primary purpose would be to provide reset and shutdown of CPU
> and Virtio devices.
>      - There will be only one instance of this device and its location will
> be fixed for each architecture.
>
> The Virtio-desktop specification may also describe a recommended memory map
> of for each architecture.
>
> Right now, only missing devices seems to be Virtio-fb, Virtio-input, and
> Virtio-power, which some of us are willing to take-up.
>
> IMHO, If we have something like Virtio-desktop specification then all
> possible guest OSes can have support for it and different hypervisor can
> emulate it without worrying about guest support.
>
> Best Regards,
> Anup

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

[Alexander Graf]

On 27.01.2013, at 15:07, Anthony Liguori wrote:

> Anup Patel <anup.patel@linaro.org> writes:
> 
>> Hi All,
>> 
>> How about having a generic Virtio-based machine for emulating a virtual
>> desktop ?
>> 
>> 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.
> 
> There's a lot of reasons why a pure PV machine type is a bad idea.  Lots
> of people have enumerated them in this thread.
> 
> But let me mention some things that I think we don't have covered today
> with PV:
> 
> - Graphics.  Yes, I know QXL exists but it's (a) dependent on PCI (b)
>   lacks the ability to gracefully degrade making it hopelessly tied to
>   spice.

There was a QXL-on-virtio port in the works a while ago IIRC:

> - Input.  PS/2 mouse provides relative input which sucks in guests.
>   For absolute input, we have VMMouse which is x86-specific, USB
>   tablets (which are expensive to emulate) or the spice mouse which is
>   intimately tied to the full Spice stack.

I thought the USB tablet is ok today thanks to auto-suspend of the bus? Or was that only with ehci?

> 
> - Guest interaction.  Copy/paste, drag and drop, etc.  In theory this
>   is covered in spice agents but it's all again hopelessly tied to
>   Spice which makes it non-portable.

- Keyboard. When running with VNC, the 3 stacks involved in converting keyboard layouts back and forth are really confusing to users.

> So there's good work todo but it's almost certainly in working with the
> Spice community to try to make what they already have more accessible to
> non-x86 architectures.

Hooray :)


Alex