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

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



Fantu <fantonifabio <at> tiscali.it> writes:

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

"without going through the Dom0" probably wasn't the best choice of words,
but what I meant was without installing and running a full graphics stack
inside the the Dom0. For example, PCI passthrough doesn't require any
graphics software in the Dom0 because the DomU talks to the graphics
hardware directly over PCI. On the other end of the spectrum, installing a
Spice/VNC/RDP client on the Dom0 requires a full graphics stack (Weston, x11
libraries, mesa, cairo, libdrm, etc) installed on the Dom0, and a lot of the
rendering takes place there too. I can install those packages in the Dom0 if
I have to, but I'm hoping to keep the Dom0 as minimal as I can while still
having usable DomU desktop interaction.

I'm only looking to display virtual machine desktops on the local hardware,
so network backends like Spice/RDP/VNC are not necessary, but I will use
them if they are more convenient that actual passthrough or emulation
methods. Although Spice and RDP do have the advantage of audio and extra
features like that unlike virtio-gpu, xen-fbfront, etc.

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

Intel's XenGT looks very promising, but unfortunately the code doesn't
appear to have reached upstream Xen or Linux, and I'm pretty sure my current
hardware doesn't even support it.

virtio-gpu/virgl also sounds promising, and it sounds like the DRM/KMS
(kernel) side of things is upstream, but I'm not sure about the upstream
status of the QEMU device or the "Virgil3D" DomU userspace (Mesa/Gallium3D
patches). This thread does however suggest it is possible to use virtio-gpu
with Xen: 
http://lists.xenproject.org/archives/html/xen-devel/2015-11/msg01797.html

I'm assuming all of these use QEMU's SDL as their host-side userspace
component (with Spice to come, as you mentioned), so I would still have to
install a graphics stack and Weston inside the Dom0.

I'm also assuming these work only for HVMs, which shouldn't be too much of a
problem, it's just my current setup uses PVs.

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

Yes, that's the project was referring to. I've never used it, but when I
heard about it I thought it might be a possible solution to my problem. I
didn't realize it was being developed out-of-tree or that it had been abandoned.

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

So, virtio-gpu/virgl does offer 3D acceleration advantages, but I still
can't use PCI passthrough without being able to passthrough the PS/2
touchpad and keyboard, I still can't install the graphics stack in a DomU
without using PCI passthrough, and I still have no idea how to use
paravirtualized DRM (http://wiki.xenproject.org/wiki/Paravirtualized_DRM) or
how it works.

I'm beginning to think putting the graphics stack inside the Dom0 is the
only feasible option (security concerns aside). That'll allow me to run the
QEMU SDL client with the simple cirrus card or the newer virtio-gpu/virgl
for HVMs, a VNC client for PVs with xen-fbfront, and a Spice client if
necessary, all with input and audio support. 

If only I could passthrough my PS/2 keyboard and touchpad, I could do that
in a DomU with only limited hardware access, but I don't know if that's
possible. Otherwise (not being able to have a minimal Dom0 OS) I might as
well run the Dom0 OS on baremetal and use QEMU/KVM, right?

Thanks for your reply Fantu. I'll look deeper into virtio-gpu and virgl, but
I still haven't quite figured out where to install the graphics stack and
what to passthrough. Hopefully someone can help me figure that out, and
answer your questions too.


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


 


Rackspace

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