Re: [Xen-users] PV desktop domU options?

[Fantu <fantonifabio@xxxxxxxxxx>]

sm8ax1 wrote
> 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?

I not understand exactly what you mean about "without going through the
Dom0".
If you mean without install client on dom0 but connecting to desktop vm from
remote I already do it, on dom0 I don't have installed a graphic interface
(I use the only as server) and I connect to the domUs with spice, from arm
thinclient full features (qxl, vdagent and usb redirection) to use windows
desktop domU with an experience like physical computer (except 3d
acceleration), before I used connect to rdp (of windows in domUs) and
proprietary usb redirection add-on (all with problems) but was bad in some
things.
For "maintenance" instead before I connect to domUs xen vnc but is bad for
dekstop, now with spice that is better.
For pv domUs instead I did only a very basic spice support for now (not
upstreamed):
http://lists.xen.org/archives/html/xen-devel/2015-12/msg00139.html
I'm insterested also in full 3d acceleration support (1 vga->multiple domUs)
but for now there are solutions only possible locally FWIK: virtio-gpu/virgl
and intel xengt.
virgl spice support for remote connection is on development but domUs driver
are only for x11 (linux domUs) for now, intel xengt have also windows driver
for domUs I saw a discussion for remote connection support but I not know
the status, I suppose will add spice support similar to virgl when will be
added.
For now I not tested them, I'm waiting at least spice support.
Any better idea or advice it is appreciated.

About Weston Spice backend I'm also interested if you mean this
(https://github.com/ein-shved/compositor-spice) but is very basic and now
abandoned by the only developer that now doing other things.
I take a fast look but I have the knowledge to continue it, seems also that
have some fast spice-specific weston changes that I suppose make it
not-upstreamable without a substantial change, or I'm wrong?


Thanks for any reply and sorry for my bad english.



--
View this message in context: 
http://xen.1045712.n5.nabble.com/PV-desktop-domU-options-tp5730169p5730171.html
Sent from the Xen - User mailing list archive at Nabble.com.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users