On 05/12/2025 18.20, Kevin Wolf wrote:
Am 05.12.2025 um 14:00 hat Thomas Huth geschrieben:
From: Thomas Huth <[email protected]>
QEMU iotests 049, 134 and 158 are currently failing if you compiled
QEMU without the crypto libraries. Thus make sure that the "secret"
object is really usable and skip the tests otherwise.
Reported-by: Alex Bennée <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
diff --git a/tests/qemu-iotests/common.rc b/tests/qemu-iotests/common.rc
index e977cb4eb61..10d83d8361b 100644
--- a/tests/qemu-iotests/common.rc
+++ b/tests/qemu-iotests/common.rc
@@ -1053,6 +1053,20 @@ _require_one_device_of()
_notrun "$* not available"
}
+_require_secret()
+{
+ if [ -e "$TEST_IMG" ]; then
+ echo "unwilling to overwrite existing file"
+ exit 1
+ fi
+ if $QEMU_IMG create -f $IMGFMT --object secret,id=sec0,data=123 \
+ -o encryption=on,encrypt.key-secret=sec0 "$TEST_IMG" 1M 2>&1 \
+ | grep "Unsupported cipher" ; then
+ _notrun "missing cipher support"
+ fi
What is the thing that you're checking here? If it's really the secret,
then just running 'qemu-io --object secret,data=123,id=sec0 -c ""' would
be enough. If it's not the secret, but encryption support, then the
function is a misnomer.
The "qemu-io" statement seems to work fine in that case, so you're right,
it's apparently not the "secret" object, but rather the "encryption" part
that is failing.
So shall I rename it to "_require_encryption" ?
_require_working_luks() looks pretty similar, though it requires
specifically a working luks driver. Could something be unified? (The
answer might be no, but it would be good to explicitly say it.)
While it looks a little bit similar, at least for me it still looks too
distinct for unification - or is "-o key-secret=sec0" doing exactly the same
as "-o encryption=on,encrypt.key-secret=sec0" ? ... I lack the deeper
understanding of the parameters here to judge on that topic.
Thomas
