Message-ID: <20250815220436.GJaJ-u9FUVTmjyaaua@fat_crate.local>
Date: Sat, 16 Aug 2025 00:04:36 +0200
From: Borislav Petkov <bp@...en8.de>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Mario Limonciello <mario.limonciello@....com>,
	Yazen Ghannam <yazen.ghannam@....com>, x86@...nel.org,
	linux-kernel@...r.kernel.org, Libing He <libhe@...hat.com>,
	David Arcari <darcari@...hat.com>
Subject: Re: [PATCH] x86/CPU/AMD: Ignore invalid reset reason value

On Fri, Aug 15, 2025 at 02:39:50PM -0700, Sean Christopherson wrote:
> You're conflating running under (on?) a hypervisor with being a guest in the
> traditional model of virtualization.  Running a privileged, host-owned software
> stack in a virtual machine is beneficial/desirable for a variety of use cases,
> and I expect the number of such use cases to grow in the near future.
> 
> E.g. as mentioned earlier, pKVM uses virtualization to de-privilege the kernel,
> and Hyper-V's VBS uses virtualization to monitor accesses to sensitive state.
> 
> Future use cases could use virtualization:
> 
>  - to improve system stability/uptime, e.g. restart the VM if the kernel crashes
>    as opposed to rebooting the entire host
>  - to isolate different software components, e.g. to run post-boot functionality
>    in a separate VM to limit the impact of an escape/flaw/bug
>  - to limit the amount of code that has direct access to system physical resources
>  - to partion a system into multiple machines (each running their own kernel)
>    for performance reason; e.g. AIUI, kernel-wide locks are becomming more and
>    more problematic as the number of cores continues to go up
> 
> Not all of those use cases will want to access "bare metal" features, but my
> point is that inferring anything about the system setup based solely on the
> HYPERVISOR flag is all but guaranteed to break sooner or later.

No, that's *exactly* why I will want to check HYPERVISOR. Because I don't know
what any of that virt zoo of paravisors, smaller layers, this and that layers
are hiding from me.

That's exactly why I cannot trust that register anymore.

Or do you have a better suggestion how am I to know in the kernel whether the
values I read from that register actually come from the hardware the feature
support was added for? Or not some funky layer in-between.

Hell, I can't even trust HYPERVISOR. Because some sneaky layer might not even
set it.

Which makes this even worse.

> That seems like a gigantic waste of time/effort.  E.g. imagine the pain/churn if
> MONITOR/MWAIT had been limited to !HYPERVISOR simply because early VM setups
> didn't support executing MONITOR/MWAIT natively.

No, that's called enablement. You test the kernel on your new hw or HV env and
then you send patches and claim support. And we support it.

> Patch loading is exceptional because, AFAIK, neither Intel nor AMD officially
> support ucode updates while running as a guest.  Though FWIW, I do expect that
> sooner or later someone will indeed want to do patch loads in a VM.

Oh, ofc. If you give the non-rebooting clouders a finger, they'll bite off the
whole hand if they can.

> I don't mind HYPERVISOR per se, what I don't like is disabling code (or going
> down different paths) based solely on historical use cases, i.e. based on the
> assumption that "no one will ever do xyz!".  I have no objection to pivoting
> on HYPERVISOR if there is an explicitly documented limitation, or for cases where
> there's a very high probability of making a bad decision, e.g. using FMS to
> enumerate features.

I don't think you're reading me here: it is not "no one will ever do". It is
"off until someone really says she will do it. And do it according to the hw
spec."

Because if she does it differently, then also crap.

So until she does it right, it is off.

-- 
Regards/Gruss,
    Boris.

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

Powered by blists - more mailing lists