We are not detecting the presence of FIPS from QEMU, but from procfs and
that means it's not QEMU capability. It was decided that we will pass
this flag to QEMU even if it's not supported by old QEMU binaries.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1135431
Signed-off-by: Pavel Hrdi
On 09/18/2014 09:52 AM, Pavel Hrdina wrote:
> We are not detecting the presence of FIPS from QEMU, but from procfs and
> that means it's not QEMU capability. It was decided that we will pass
> this flag to QEMU even if it's not supported by old QEMU binaries.
>
> Resolves: https://bugzilla.redhat.
On 09/18/2014 06:29 PM, Eric Blake wrote:
On 09/18/2014 09:52 AM, Pavel Hrdina wrote:
We are not detecting the presence of FIPS from QEMU, but from procfs and
that means it's not QEMU capability. It was decided that we will pass
this flag to QEMU even if it's not supported by old QEMU binaries.
On 09/18/2014 06:48 PM, Eric Blake wrote:
On 09/18/2014 10:44 AM, Pavel Hrdina wrote:
Ouch. This will make our testsuite differ based on whether it is run on
Linux in FIPS mode (where FIPS might exist) or on any other setup. I
think you need to hoist the check for virFileExists() to the calle
On 09/18/2014 10:44 AM, Pavel Hrdina wrote:
>> Ouch. This will make our testsuite differ based on whether it is run on
>> Linux in FIPS mode (where FIPS might exist) or on any other setup. I
>> think you need to hoist the check for virFileExists() to the caller, and
>> pass in the result as a ne
On 09/18/2014 10:55 AM, Pavel Hrdina wrote:
> On 09/18/2014 06:48 PM, Eric Blake wrote:
>> On 09/18/2014 10:44 AM, Pavel Hrdina wrote:
>>
Ouch. This will make our testsuite differ based on whether it is
run on
Linux in FIPS mode (where FIPS might exist) or on any other setup. I
>>>