[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-users] PV desktop domU options?


I'm looking to use Xen on my laptop for interacting with one or more graphical desktop PVs. My question is what are the advantages and disadvantages to the different desktop interaction methods? Note that I'm trying to do this without X at all, or at least only involve X on some PVs which require it. Instead, I'd like to use Wayland/Weston with DRM if possible. I have intel i915 graphics and Intel snd_hda_intel audio (appear as PCI devices), but only PS/2 (serial) keyboard and touchpad, no USB. Xen 4.6.0 with XL.

Method 1:
Install Weston (and all its dependencies: mesa, cairo, xkbd, xcb/xlib, etc) and VNC/Spice/RDP clients (and all their dependencies) in the Dom0. Then I can connect to HVMs that use the emulated VGA adapter over VNC/Spice, and PVs using xen-fbfront or install the Weston Spice backend or a VNC server inside the PV.

This is the easiest option as Dom0 is the only domain that interacts with the hardware. I'll lose graphics acceleration but it might not be that bad with Weston and the Spice+QXL backend. However, I really don't want that much code (Weston, mesa, clients, etc) running in the Dom0 for performance and security reasons. I would feel better if most of the rendering code could be run in the DomU and the results passed-through over a well-defined interface like fbdev, DRM, or PCI (as in PCI passthrough).

Method 2:
Install DirectFB and DirectVNC in the Dom0 and use xen-fbfront (CONFIG_XEN_FBDEV_FRONTEND) in the PVs. This makes for a smaller Dom0 footprint, but is subject to a lot of the same limitations as method 1. Since both of those projects are rather unmaintained, and the Linux fbdev is becoming deprecated, I don't know how feasible it will be to get it working (and keep it working). Once again I'll lose graphics acceleration, and DirectFB and DirectVNC are still subject to compromise on the Dom0.

Method 3:
PCI passthrough graphics and audio into the PVs. I'll get graphics acceleration and audio, but I don't see any way to pass through a PS/2 keyboard and touchpad, so I'll have output but no input. Socat might be able to pass /dev/input/* into the PV over the network, but even if it works it seems like quite a hack. I'll also only be able to use one PV desktop at a time, and switching back to the Dom0 will be difficult, but I could use method 1 on the primary desktop DomU to connect to other DomUs, protecting the Dom0 and keeping it as minimal as possible.

Method 4:
Like method 2, but use http://wiki.xenproject.org/wiki/Paravirtualized_DRM instead of paravirtualized fbdev. This will theoretically give me graphics acceleration and DRM is better maintained. That wiki page only talks about troubleshooting and upstream status, however, and makes no mention of how to use paravirtualized DRM at all, and I can't find any mainline 4.2.3 kernel config/module that resembles Xen PV DRM. Keyboard and touchpad are also a problem as in method 3.

From this I gather that using a DomU as a desktop without going through the Dom0 (much) is a fairly uncommon thing. So is there any good solution? How are most people using Xen on desktop systems?



ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options!
Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.