------- Comment From cborn...@de.ibm.com 2020-04-24 06:08 EDT------- (In reply to comment #9) > (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.
I think the proper solution is to rebuild the capabilities whenever the date of /dev/kvm changed. There are module parameters (hpage and nested) that will change the capabilities. Caching beyond the lifetime of /dev/kvm is just wrong. When the startup takes slightly longer after reboot - so be it. Agreed to discuss this upstream. Please cc me -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1874647 Title: [Ubuntu 20.04] Stale libvirt cache leads to VM startup failures To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1874647/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
