[Spice-devel] [PATCH v4] libxl: add basic spice support for pv domUs

[Ian Campbell]

On Tue, 2014-05-13 at 12:51 +0200, Fabio Fantoni wrote:
> Il 13/05/2014 11:50, Ian Campbell ha scritto:
> > On Tue, 2014-05-13 at 10:00 +0200, Fabio Fantoni wrote:
> >>> But: Does spice already require a VFB? In which case the existing
> >>> handing of that will suffice.
> >>>
> >>> I think I'm probably confused about something: Does this patch
> >>> enable/expose SPICE to the guest? Or does it simply enable the existing
> >>> PVFB's output to be exposed from the qemu process to a spice client? I
> >>> had been thinking this was a parallel feature to PVFB, but I'm starting
> >>> to suspect this might actually be an additional feature *of* PVFB, which
> >>> is correct? (I'm afraid that depending on which it is I might have to
> >>> check back over my review to make sure I haven't suggested anything
> >>> stupid)
> >>>
> >>> Does QXL change that answer?
> >> QXL and other emulated vga is now not supported on pv domUs because
> >> require an emulated pci bus and MMIO not supported on pv domUs FWIK.
> > Right, but what about the previous paragraph? That was the important bit
> > for me to understand, since it impacts the entire configuration model
> > and libxl API.
> >
> >> During my first test, I was enabled spice in pv domus but the guest wont
> >> show nothing while connecting to it.
> >> On my second shot, I've added -vga xenfb but it is deprecated. This way
> >> I've got at least video out but no mouse nor keyboard.
> >> Following the suggestions from Stefano Stabellini I've then activated
> >> vfb the same way as for vnc and i got it all working but mouse, which is
> >> only visible in some circumstances (such grafical debian installer) but
> >> always working (even if not visible).
> >> The last one is the actual patch.
> >> Probably the vfb part is not complete or at least improvable.
> >> Perhaps it is even not necessary if pvfb will became modified to works
> >> with spice, so domUs use this through its modules.
> > Is SPICE a mechanism for exposing the PVFB or is it something entirely
> > separate? That is the crux of my question above.
> 
> I added also qemu-devel and spice-devel on cc:
> Any one on this please?
> 
> >
> >> I feel I'm not perfectly undrestanding pvfb. Please would you like
> >> better describe me this component?
> > I need to understand what it is this patch is actually doing. I'm
> > starting to worry that perhaps you don't understand either.
> 
> Make possible using spice with basic features also on pv domUs.

*How* is the important thing. How is SPICE exposed to the guest? How is
SPICE exposed to the user/client?

I'm a bit surprised you've been pushing a patch to enable something
without knowing the answers to these sorts questions. If you don't
understand what it does how do you know it is doing the correct thing,
and how can you therefore explain it to the person reviewing the patch?

> Since emulated vgas is not supported on pv I use vfb instead, even if 
> this part is incomplete and rudimental.

What is incomplete and rudimentary?

> I'm waiting from some aswers from spice and qemu teams to share some 
> light on the question above.
> 
> Thanks for any reply and sorry for my bad english.
> 
> >
> >> Another thing: i noticed that vnc has all its parameters duplicated in
> >> vfb too. For the moment I omissed them since i feel they are not
> >> necessary - aren't they
> > It really depends on the answer to my questions above.
> >
> > If SPICE is nothing to do with PVFB then it obviously makes no sense for
> > it to be separate.
> >
> > If SPICE is just a backend for PVFB then it actually makes *more* sense
> > to expose spice as a PVFB configuration parameter than as a set of top
> > level options. The fact that VNC is exposed as a top level thing too is
> > somewhat anomalous but was done for xend compatibility (nb: it is the
> > top level duplicating the vfb VNC settings, not vice versa IMHO).
> >
> > Ian.
> >