> >>> 2) check if /dev/sev device exist (aka firmware is detected)
> >> This seems reasonable. Shouldn't it have been documented in
> >> docs/kbase/launch_security_sev.rst?
> > Sure, we can add a mention about this. Although, doesn't 1 imply 2? IOW can
> > you have the kernel module parameter set to 1 and yet kernel doesn't expose the
> > /dev/sev node?
>
>
> Currently, 1 does not imply 2, KVM driver does not initialize the
> firmware during the feature probe (i.e does not access the /dev/sev).
> The firmware initialization is delayed until the first guest launch. So
> only sane way to know whether firmware is been detected is check the
> existence of the /dev/sev or issue a query-sev command . The query-sev
> command will send the platform_status request to the firmware, if the
> firmware is not ready then this command will fail.
I see. Can query-sev fail or return that it's disabled, aka {"enabled":
false,...} in the SevInfo QMP response, but at the same time succeed in
returning the platform capabilities via query-sev-capabilities? I'm asking,
because libvirt only issues the latter to fill in the QEMU capabilities
structure.
--
Erik Skultety
