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