On Mon, Oct 18, 2021 at 01:40:03PM -0500, Michael Roth wrote:

If CPUID has lied, that would result in a #GP, rather than a controlled
termination in the various checkers/callers. The latter is easier to
debug.

Additionally, #VC is arguably a better indicator of SEV MSR availability
for SEV-ES/SEV-SNP guests, since it is only generated by ES/SNP hardware
and doesn't rely directly on hypervisor/EFI-provided CPUID values. It
doesn't work for SEV guests, but I don't think it's a bad idea to allow
SEV-ES/SEV-SNP guests to initialize sev_status in #VC handler to make
use of the added assurance.

Ok, let's take a step back and analyze what we're trying to solve first.
So I'm looking at sme_enable():

1. Code checks SME/SEV support leaf. HV lies and says there's none. So
guest doesn't boot encrypted. Oh well, not a big deal, the cloud vendor
won't be able to give confidentiality to its users => users go away or
do unencrypted like now.

Problem is solved by political and economical pressure.

2. Check SEV and SME bit. HV lies here. Oh well, same as the above.

3. HV lies about 1. and 2. but says that SME/SEV is supported.

Guest attempts to read the MSR Guest explodes due to the #GP. The same
political/economical pressure thing happens.

If the MSR is really there, we've landed at the place where we read the
SEV MSR. Moment of truth - SEV/SNP guests have a communication protocol
which is independent from the HV and all good.

Now, which case am I missing here which justifies the need to do those
acrobatics of causing #VCs just to detect the SEV MSR?

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette