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@xxxxxxxxxx> --- 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@xxxxxxxxxx> John
psst, it would be nice if you removed the irrelevant parts below in your reply, like this, look:
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
