Re: [PATCH] tests/qemu-iotests: Check for a functional "secret" object before using it

[Thomas Huth <thuth@redhat.com>]

On 05/12/2025 18.20, Kevin Wolf wrote:
> Am 05.12.2025 um 14:00 hat Thomas Huth geschrieben:
>> From: Thomas Huth <thuth@redhat.com>
>>
>> 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 <alex.bennee@linaro.org>
>> Signed-off-by: Thomas Huth <thuth@redhat.com>
> 
>> 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