On Mon, Feb 07, 2022 at 11:00:18AM -0600, Michael Roth wrote:
> this is more a statement that an out-of-spec hypervisor should not
> expect that their guests will continue working in future firmware
> versions, and what's being determined here is whether to break
> those out-of-spec hypervisor now, or later when/if we actually
> make use of the fields in the guest code,
I think you're missing a very important aspect here called reality.
Let's say that HV is a huge cloud vendor who means a lot of $ and a
huge use case for SEV tech. And let's say that same HV is doing those
incompatible things.
Now imagine you break it with the spec change. But they already have
a gazillion of deployments on real hw which they can't simply update
just like that. Hell, cloud vendors are even trying to dictate how CPU
vendors should do microcode updates on a live system, without rebooting,
and we're talking about some wimpy fields in some table.
Now imagine your business unit calls your engineering and says, you need
to fix this because a very persuasive chunk of money.
What you most likely will end up with is an ugly ugly workaround after a
lot of managers screaming at each other and you won't even think about
breaking that HV.
Now imagine you've designed it the right and unambiguous way from the
getgo. You wake up and realize, it was all just a bad dream...
> Ok, I'll follow up with the firmware team on this. But just to be clear,
> what they're suggesting is that the firmware could enforce the MBZ checks
> on the CPUID page, so out-of-spec hypervisors will fail immediately,
> rather than in some future version of the spec/cpuid page, and guests
> can continue ignoring them in the meantime.
Yes, exactly. Fail immediately.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
