Hi,

On Mon, Mar 14, 2016 at 04:00:11PM +0100, Gerd Hoffmann wrote:
> On Mo, 2016-03-14 at 12:41 +0100, Christophe Fergeau wrote:
> > Currently, virgl support has to go through a local unix socket, trying
> > to connect to a VM using -spice gl through spice://localhost:5900 will
> > only result in a black screen.
> > This commit errors out when the user tries to start a VM with both GL
> > support and a port/tls-port set.
> > This would fit better in spice-server, but currently QEMU does not call
> > into spice-server when parsing 'gl' on its command line, so we have to
> > do this check in QEMU instead.
> 
> Hmm.  It's something which we want support long-term though, by encoding
> those dma-bufs as video stream and send them off over tcp.
> 
> I don't think this is a good idea long-term.

Yes, long-term we will want to remove this once spice gets support for
this. Currently however, this imo makes it a bit easier to understand
how everything is setup.
Otherwise I expect people are going to just take their existing SPICE
libvirt configuration listening on the network, add <gl enable="yes"/>
to it, try remote-viewer spice://localhost:5900 and wonder why they get
a black screen, and not know whether this is because their guest does
not support virgl, or their host, or because of some other issue, ...

Having this as a stopgap ensures that they at least be informed this is
not a valid usecase.

> And even as temporary stopgap:  Can libvirt + virt-manager handle this?

libvirt can, I haven't tried virt-manager (I believe all the patches
from Marc-André haven't been pushed yet)
<spice autoport="no"/> starts QEMU with -spice port=0

Christophe