Re: [Xen-devel] [PATCH v2 2/2] libxl: Fix nographic with upstream qemu

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-12-18 at 21:15 +0100, Sander Eikelenboom wrote:
> Wednesday, December 18, 2013, 8:54:39 PM, you wrote:
> 
> > 2013/12/18 Sander Eikelenboom <linux@xxxxxxxxxxxxxx>
> 
> >> Hello Sander,
> >>
> >> Tuesday, November 26, 2013, 1:30:41 PM, you wrote:
> >>
> >>
> >> > Tuesday, November 26, 2013, 12:53:09 PM, you wrote:
> >>
> >> >> On Mon, Nov 25, 2013 at 08:39:22PM +0100, Sander Eikelenboom wrote:
> >> >>>
> >> >>> Monday, November 25, 2013, 8:28:27 PM, you wrote:
> >> >>>
> >> >>> > 2013/11/25 Anthony PERARD <anthony.perard@xxxxxxxxxx>
> >> >>>
> >> >>> >> On Tue, Nov 19, 2013 at 03:57:09PM +0100, Fabio Fantoni wrote:
> >> >>> >> > Fix xl nographic parameter with upstream qemu using vga none
> >> >>> >> > instead of -nographic qemu parameter not working anymore and
> >> >>> >> > deprecated.
> >> >>> >> >
> >> >>> >> > Changes from v1:
> >> >>> >> > - libxl_create.c:
> >> >>> >> >  - add vga=none if nographic=1 only with upstream qemu
> >> >>> >> >  - move setdefault of nographic up, otherwise xl create will
> >> >>> >> >    fail if nographic xl paramter is not set
> >> >>> >>
> >> >>> >> Could you tell me where it is said that -nographic is deprecated?
> >> >>> >>
> >> >>>
> >> >>> > On one old qemu-devel post if I remember good, I not found it now
> >> with fast
> >> >>> > search.
> >> >>>
> >> >>> this one of mine:
> >> >>> http://osdir.com/ml/xen-development/2013-10/msg00134.html
> >> >>>
> >> >>> which refers to a post on qemu-devel:
> >> >>> http://comments.gmane.org/gmane.comp.emulators.qemu/172385
> >>
> >> >> Thanks for the pointers.
> >>
> >> >>> >>
> >> >>> >> Also, I've did few tests, and it look like nographic=1 still works
> >> well.
> >> >>> >>
> >> >>>
> >> >>> > When I did a tests time ago with upstream qemu gave always cirrus
> >> vga with
> >> >>> > hvm domUs, also with vga and stdvga not setted and nographic on.
> >> >>> > Tried also removing my patches about -nodefaults but same result.
> >> >>> > When I did this patches I found that xl setted cirrus in any case
> >> and also
> >> >>> > with -nographic with upstream qemu not override -vga or -device.
> >> >>>
> >> >>>
> >> >>> >>
> >> >>> >> In QEMU, "-vga none" and "-nographic" are two different things. The
> >> >>> >> first parameter disable the graphic emulation, which mean you can
> >> have a
> >> >>> >> guest without graphic card (lspci will show that). The second one
> >> is to
> >> >>> >> disable any graphic output (sdl, vnc, ...).
> >> >>> >>
> >> >>> >> The only issue might be the documentation.
> >> >>> >>
> >> >>>
> >> >>> > Sorry, about qemu traditional I haven't well documented, but on this
> >> patch
> >> >>> > I setted nographic equivalent to vga none only with upstream qemu,
> >> so the
> >> >>> > qemu-trad remain correctly.
> >> >>> > Another note, I use spice with upstream qemu instead of vnc (because
> >> is
> >> >>> > largely better), probably -nographic not disable it.
> >> >>>
> >> >>> > Sumarizing, previous patch about vga none after new version
> >> following your
> >> >>> > advice can be useful in any case.
> >> >>> > About nographic instead I am doubtful about how to proceed, I think,
> >> >>> > however that an improvements and/or more documentations are needed.
> >> >>> > Ideas or tips about nographic?
> >>
> >>
> >> >> After reading those threads about nographic deprecation, it is said that
> >> >> it is better to use '-display none' instead of '-nographic'.
> >> >> So '-display none' just mean you get no VNC, no SDL window, no SPICE,
> >> >> nothing, but you can still get a graphic card in the guest, with no way
> >> >> to display its output.
> >>
> >> >> I suppose 'nographic' xl options should keep the same effect which is no
> >> >> graphic output. So if you want a guest without graphic card, then your
> >> >> new 'vga=none' will be for you.
> >>
> >> > Wouldn't it be more natural to do just
> >> > vnc=0
> >> > sdl=0
> >> > vga=none
> >>
> >> > if i want no graphics?
> >>
> >> > Instead of making a "meta-option" which overrules other available
> >> options ?
> >> > Would simplify the parsing for libxl as well.
> >>
> >> Hi Anthony / Fabio,
> >>
> >> Just a little *ping* here ..
> >> I haven't seen a response any more, nor seem Fabio's patches to be applied.
> >>
> 
> > The first patch with v3 should be good:
> > http://lists.xen.org/archives/html/xen-devel/2013-12/msg00725.html
> > and vga none can be useful in some cases but probably will be applied only
> > with xen 4.5 because 4.4 is on freeze and near to first rc.
> 
> Yes i have added it to my private patch queue now, thx :-)
> 
> > About the second patch after Anthony reply I understand that the patch is
> > bad, I do not know how to improve this part in the best way and I'm
> > currently busy with many other things.
> 
> Yes but i wasn't convinced and haven't seen a response from Anthony to that.
>
> Because having such a meta-option that effects the behaviour of a set of 
> individual options
> seems to make the problem of precedence appear which is ambiguous.

A meta-option by its very nature takes precedence.

> f.e. if I specifying vnc=1 and nographic=1 .. should vnc be on or off now, so 
> which option
> should take precedence over the other ?

It should either error out as a contradictory configuration or
nographic=1 should take precedence.

> So i don't see the real benefit of a meta-option above just switching the 
> individual components on or off.

I think having a single big switch is useful, if I know I don't want
graphics then I shouldn't have to go and hunt down all the various
things which might make graphics be turned on.

Consider what happens if a new type of graphics backend gets introduced
(first we had sdl and VNC, then we gained spice, what comes next?). I
don't want gfx getting turned on just because I didn't notice and go and
find out what the next interface is.

> If you want them all off .. then just specify that.
> 
> The less ambiguous the better i would say.
> 
> 
> >>
> >> --
> >> Sander
> >>
> >> > --
> >> > Sander
> >>
> >>
> >>
> >> --
> >> Best regards,
> >>  Sander                            mailto:linux@xxxxxxxxxxxxxx
> >>
> >>
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel



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