On 5/12/20 5:32 PM, Erik Skultety wrote:
I leave 1) and 2) to the AMD experts... :-)
3) Check if Qemu supports SEV feature (maybe we can detect the existence
of the query-sev QMP command or detect Qemu version >= 2.12)
^This is already achieved by qemuMonitorJSONGetSEVCapabilities
The idea is to check the host capabilities to detect if qemus capabilities
need to be reprobed. Therefore this would be a result if checks 1+2 change
but it would not be a cache invalidation trigger.
I agree in the sense that the SEV support that is currently being reported in
QEMU capabilities wasn't a good choice because it reports only platform data
which are constant to the host and have nothing to do with QEMU. It would be
okay to just say <sev supported="yes|no"/> in qemu capabilities and report the
rest in host capabilities. I haven't added this info into host capabilities
when I realized the mistake because I didn't want to duplicate the platform
info on 2 places. For the IBM secure guest feature, it makes total sense to
report support within host capabilities, I'm just not sure whether we should do
the same for SEV and try really hard to "fix" the mess.
I am not sure I understand the "mess" correctly.
The idea is to prevent the cached qemu capabilities becoming stale which
Daniel PB has called earlier a bug in the caching algorithm. This can
occur if the kernel or firmware configuration change. To find out these
situations we try to implement qemu capability cache invalidation
triggers. The monitor method you mentioned is called during a (re-)probe
and for IBM Secure Execution the host CPU model is also updated during a
(re-)probe. Wouldn't that clean up the "mess"?
--
Mit freundlichen Grüßen/Kind regards
Boris Fiuczynski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
