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 [...] -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
