c) refactor SEV-ES handling as part of this series. it's only a small changeDefinitely (c). This has already missed 5.11 (unless Paolo plans on shooting
to the SEV-ES code but it re-orders enough things around that I'm
concerned it might invalidate some of the internal testing we've done.
whereas a follow-up refactoring such as the above options can be rolled
into our internal testing so we can let our test teams re-verify
Obviously I prefer b) but I'm biased on the matter and fine with whatever
you and others think is best. I just wanted to point out my concerns with
the various options.
from the hip),
which means SEV-ES will get to enjoy a full (LTS) kernel release
before these optimizations take effect.