[libvirt] [PATCH 4/5] qemu: Add capability flag for setting the extended tseg size

[Martin Kletzander]

On Wed, May 30, 2018 at 12:23:12PM -0400, John Ferlan wrote:
>
>
>On 05/21/2018 11:00 AM, Martin Kletzander wrote:
>> Signed-off-by: Martin Kletzander <mkletzan at redhat.com>
>> ---
>>  src/qemu/qemu_capabilities.c                  | 10 +++
>>  src/qemu/qemu_capabilities.h                  |  2 +
>>  .../caps_1.5.3.x86_64.replies                 | 38 +++++++++--
>>  .../caps_1.5.3.x86_64.xml                     |  3 +-
>>  .../caps_1.6.0.x86_64.replies                 | 38 +++++++++--
>>  .../caps_1.6.0.x86_64.xml                     |  3 +-
>>  .../caps_1.7.0.x86_64.replies                 | 38 +++++++++--
>>  .../caps_1.7.0.x86_64.xml                     |  3 +-
>>  .../caps_2.1.1.x86_64.replies                 | 38 +++++++++--
>>  .../caps_2.1.1.x86_64.xml                     |  3 +-
>>  .../caps_2.10.0.x86_64.replies                | 48 ++++++++++---
>>  .../caps_2.10.0.x86_64.xml                    |  3 +-
>>  .../caps_2.12.0.x86_64.replies                | 67 +++++++++++++++----
>>  .../caps_2.12.0.x86_64.xml                    |  4 +-
>>  .../caps_2.4.0.x86_64.replies                 | 38 +++++++++--
>>  .../caps_2.4.0.x86_64.xml                     |  3 +-
>>  .../caps_2.5.0.x86_64.replies                 | 40 +++++++++--
>>  .../caps_2.5.0.x86_64.xml                     |  3 +-
>>  .../caps_2.6.0.x86_64.replies                 | 40 +++++++++--
>>  .../caps_2.6.0.x86_64.xml                     |  3 +-
>>  .../caps_2.7.0.x86_64.replies                 | 40 +++++++++--
>>  .../caps_2.7.0.x86_64.xml                     |  3 +-
>>  .../caps_2.8.0.x86_64.replies                 | 40 +++++++++--
>>  .../caps_2.8.0.x86_64.xml                     |  3 +-
>>  .../caps_2.9.0.x86_64.replies                 | 48 ++++++++++---
>>  .../caps_2.9.0.x86_64.xml                     |  3 +-
>>  26 files changed, 458 insertions(+), 104 deletions(-)
>>
>
>Is there no other way to determine this without getting mch? and needing
>to update all those replies from earlier releases? I assume those are
>there because "mch" exists in 1.5.3 and beyond, but we never checked for
>it. So did you update the .replies files manually or did you run this
>against each version mentioned?
>

I, personally ran tests/qemucapsprobe for newest QEMU from git and for the
oldest one we have replies for in the repo (1.5.3).  That way I got the reply
for positive and negative result.  I then copied the positive one to all QEMU
versions that support it and the other one to those that don't.  Then the next
step is pretty important, I added the parameter to all of the outputs to check
that the reply is in the right position in the file.  I then fixed those where
the position was slightly different (cleanly seen by the capability not being
ther even though it should), removed the parameter and ran
tests/qemucapsfixreplies for all the files.

I'll add that to the commit message and I'll be reposting the series again
anyway, so you can say whether that's looks like you imagined it or not.

>Personally I think it's always a bonus if how the replies adjustments
>were made is described. It perhaps helps the next person with the same
>conundrum.
>

Everyone is talking about how we could have some images with all the QEMUs and
automatically update it...  But because this is once per (quite a long) time
that someone has to do this nobody is really pressed to make this more
streamlined, because once you fix it for your particular capability, you no
longer have the need.  Pavel is closest to this as he has bunch of VMs, one for
each QEMU version, but still has to run the update manually.

>Is there no other way to get this without supplying the "mch"/MCH as well?
>

It's a parameter of the MCH device that exists (or rather is exposed) only on
x86_64 machines (MCH is/used to be the north bridge in the PC).  Without knowing
whether it exists we don't know if we can ask QEMU about the device.  We could
do that without the capability itself and then try to parse the error message
etc., but why?  Also this just is how the virQEMUCapsObjectTypeProps is
structured.

>In any case, with some minor updates to the commit message to give a
>synopsis related to how the .replies were updated...
>
>Reviewed-by: John Ferlan <jferlan at redhat.com>
>
>John
>

psst, it would be nice if you removed the irrelevant parts below in your reply,
like this, look:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180531/6be1b8bd/attachment-0001.sig>