On Fri, 2016-05-13 at 13:51 -0400, Cole Robinson wrote:
>
> +/* Capabilities that we assume are always enabled
> + * for QEMU >= 0.12.0 */
> +static void
> +virQEMUCapsInitHelpBasic(virQEMUCapsPtr qemuCaps)
> +{
> +
> + /* Although very new versions of qemu advertise the presence of
> + * the rombar option in the output of "qemu -device pci-assign,?",
> + * this advertisement was added to the code long after the option
> + * itself. According to qemu developers, though, rombar is
> + * available in all qemu binaries from release 0.12 onward.
> + * Setting the capability this way makes it available in more
> + * cases where it might be needed, and shouldn't cause any false
> + * positives (in the case that it did, qemu would produce an error
> + * log and refuse to start, so it would be immediately obvious).
> + */
> + virQEMUCapsSet(qemuCaps, QEMU_CAPS_PCI_ROMBAR);
> +
> + virQEMUCapsSet(qemuCaps, QEMU_CAPS_VIRTIO_BLK_SG_IO);
> + virQEMUCapsSet(qemuCaps, QEMU_CAPS_CPU_HOST);
> +}
As Pavel said, the approach we've taken for other flags is to rename them to
X_$NAME, and remove all code usages. Moving these flags to their own function
confuses that approach, so I suggest either give the X_$NAME treatment to each
of those flags, or just using this series to disable PCI_ROMBAR and leave the
other flags for a later series.
I hadn't noticed that pattern, and it makes much more sense
than what I'm doing here - setting a capability unconditionally
and never checking for its presence seemed kinda off, glad you
guys caught it and suggested a better solution before I had a
chance to push :)
--
Andrea Bolognani
Software Engineer - Virtualization Team