[Xen-users] PV desktop domU options?

[sm8ax1@xxxxxxxxxxx]

Hi,

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?
Thanks


-------------------------------------------------

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
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users