Comment 4 for bug 1874647

------- Comment From <email address hidden> 2020-04-24 06:03 EDT-------
(In reply to comment #8)
> The case with the module parameter in SEV needs a fix similar to
> https://libvirt.org/git/?p=libvirt.git;a=commit;
> h=b183a75319b90d0af5512be513743e1eab950612
> as it can be re-loaded at any time.
>
> Essentially the checks in virQEMUCapsLoadCache check qemu/kernel version and
> many other things.
> They also check microcode version ...
>
> I think the decision there can be two ways, either "on any reboot we need to
> refresh caps" which makes the code small but probably also wastes quite some
> refreshes that were not needed.
> Or it could along all the versions that it checks also keep a full string of
> /proc/cmdline and compare it. If changed it needs to be refreshed.
>
> I agree to Frank that this should be reported upstream.
> No matter if you or I write a fix, it needs to go upstream then - so a bug
> tracker there can't hurt.
> OTOH you can as well start right away with a RFC patch there if you have
> something prepared already - there is no "strict need" for an upstream bug,
> only if you hope someone there will fix it for you.
>
> Since workarounds are available the prio is medium IMHO, eager to see what
> upstream thinks.
>
> P.S. Even if you have no patch, it would be great if you (as the affected)
> would kick off the discussion upstream. Please provide a link here to the
> mailing list entry.

I agree with you. Please regard this as a tracking bug to pick up the upstream commits.

We (IBM) will prepare a write up for Secure Execution comparable to what exists for AMD SEV and also provide a fix for the cap caching invalidity problem. If that is going to look similar for what was done for nesting needs to be seen but it is a good starting point. Thanks for providing it.