[libvirt] [PATCH] qemu: add sdl opengl support

[John Ferlan]

On 05/08/2018 10:12 AM, Maciej Wolny wrote:
> 
> 
> On 04/05/18 00:08, John Ferlan wrote:
>> BTW: Since your patches add a capability - I would have expected a
>> change to add a flag to one (or more) of the
>> tests/qemucapabilitiesdata/caps_*.xml files, but none are modified.  So
>> that means that the feature may not be introspectable, perhaps it's been
>> part of qemu since 1.5 or it's something being added to the next qemu
>> release. If it's a new feature, then when was it added? If it's been
>> there since 1.5, then no capability flag is required.
> 
> I'm going to need some help understanding the QEMU capabilities test
> (tests/qemucapabilitiestest.c). As I understand it, it run QEMU to get
> the capabilities and then compares that to the XML file containing the
> expected list of capabilities. What are the *.replies files used for?
> And how is it do that on multiple architectures and QEMU versions
> at the same time?
> 

Sorry for the delay in getting back to you on this...  The .replies file
is the "response" from qemu for the capabilities requests made against
each architecture for each QEMU version they are run against. Let's say
you have your qemu 2.12 executable (in my case qemu-system-x86_64), then
you run:

tests/qemucapsprobe /path/to/qemu-system-x86_64 >
tests/qemucapabilitiesdata/caps_2.12.0.x86_64.replies

And that generates the replies file for at QEMU version and that
architecture.

That data is sourced by the running the various probes and queries from
the virQEMUCaps* structures in qemu_capabilities.c against the version
specific emulator file.

I see you've posted a v2 - I'll look at that later, but in that posting
you only updated the 2.4 caps. I assume you figured out more or less how
they work and hand edited the file.  While that works, you only modified
the 2.4 one and not the caps for 2.5 and beyond... So that probably
won't work right, but I'll address that while reviewing.

In any case, here's the issue - "I think" - it doesn't seem the -gl
option from "sdl" is introspectable. The $QEMU/vl.c code seems to handle
the parsing for "sdl" quite differently and that could mean we need to
run with the other hack^W mechanism to define a capability... In
virQEMUCapsInitQMPMonitor you'll see a series of "if (qemuCaps->version
>=" checks which set some specific CAPS flags - I think that's what may
need to be done.

However, I also note in qemu 2.12, there's a ui.json which seems like it
could be a mechanism used to introspect or use QMP in order to determine
when/if some command line option exists and has some new flag/option.
I'm not sure how the DisplayOptions are used and whether they are even
used for sdl -gl. But with the mechanism from the previous paragraph -
then at least everything from qemu 2.4 and beyond will get the sdl -gl
capability.

>>
>> How that us determined for sdl is a mystery to me... I usually search
>> through the qemu */*.json files. In this case I do find some remnants of
>> 'gl' and 'sdl' in qapi/ui.json.  But how I read that output is that for
>> 2.12 there's 'sdl' in DisplayOptions, but using 'DisplayNoOpts' which
>> could mean no options for sdl are allowed, but I'm not sure. Maybe there
>> is some change in flight - I don't follow qemu-devel that closely.
>>
>> If I look back at commit id '937ebba00e' for the spice-gl addition
>> (which yes, was one in one patch) - I can relate that to the similar
>> spice gl fetch, but looking the recent top of qemu git tree, I don't see
>> how this same mechanism can be used to determine whether the running
>> qemu supports sdl using gl.
> 
> It looks like this option was introduced to QEMU in 0b71a5d5. v2.4.0 is
> the earliest release which contains that commit.
> 

We can use this qemu commit id in the patch 4 of your v2... Thanks for
looking it up!

John

[...]