On Wed, Jun 03, 2020 at 11:11:08 +0200, Michal Privoznik wrote: > On 6/3/20 10:40 AM, Peter Krempa wrote: > > On Wed, Jun 03, 2020 at 10:27:57 +0200, Michal Privoznik wrote: > > > On 6/3/20 9:31 AM, Peter Krempa wrote: > > > > QEMU added the machine types for the 5.1 release so let's update them. > > > > > > > > Other notable changes are 'cpu-throttle-tailslow' migration property, > > > > 'zlib' compression for qcow2 images and absrtact socket support. > > > > > > > > Signed-off-by: Peter Krempa <pkrempa@xxxxxxxxxx> > > > > --- > > > > As usual, I'll be refreshing this until the release so that we always > > > > have fresh capabilities to prevent any surprises with deprecation and > > > > big updates. > > > > > > > > .../domaincapsdata/qemu_5.1.0-q35.x86_64.xml | 2 +- > > > > .../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 2 +- > > > > tests/domaincapsdata/qemu_5.1.0.x86_64.xml | 2 +- > > > > .../caps_5.1.0.x86_64.replies | 357 +++++++++++------- > > > > .../caps_5.1.0.x86_64.xml | 14 +- > > > > 5 files changed, 237 insertions(+), 140 deletions(-) > > > > > > Reviewed-by: Michal Privoznik <mprivozn@xxxxxxxxxx> > > > > > > Maybe we can have another rule that would allow you to push these without > > > review? I can argue both ways, so I'm just putting it out there. > > > > Yeah. I thought about that too. > > > > Specifically one thing I'd like to avoid is carelessness in case of the > > update. Specifically if there is some form of removal (flag being > > removed and such) we need to be careful and consider the implications. > > Well, for that we would need to compare with older capabilities XML and I > don't think we are doing that. Removal between the same capabilities XML of I certainly am doing that when generating files after the release to ensure that we don't regress in anything. Obviously only on the level of detected capabilities. > an unreleased QEMU are uncommon. But I hear what you're saying and that's my > concern too. > > > > > In this very specific case there's nothing of note and I'd be okay with > > just pushing it, but the rules if we wanted to codify it somehow would > > require to be more nuanced and I don't think I can express all the > > caveats. > > > > That's why I didn't really argue for adding a special rule for this. > > > > Also one reason I'm doing periodic upgrades of this is so that others > > don't have to do it. The problem here is that the output is very much > > dependent on the machine where you run it and I don't want others to > > have to update the files when adding a new capability as the difference > > becomes unreviewable and may even regress depending on how qemu is > > built. > > > > This is a long known issue and perhaps it would be worth documenting > somewhere? I think these are QEMU binaries taken from Fedora, is that so? Well. They are built on fedora, but certainly not taken from fedora. It's built from git. > Maybe we can document configure arguments for QEMU so that it is > reproducible. While I agree that we should do that to take one of the moving parts out of the equation we still can't do anything about the machine dependance of the output. Specifically it contains all cpu flags so it really can't be re-generated reproducibly on a box with even a slightly different cpu. Ideally we'd build it with the fedora spec-file, but I got lazy and I'm usually just re-running configure from my history in this case. My only idea how to provide stable output is to create a job on a box which will periodically re-build qemu and fetch the capabilities and publish them somewhere so that others could grab those and refresh the caps themselves, but I can't really think of a way how to enable others do it on their machine whithout messing up the CPU.
