Re: [PATCH v2] x86/amd: do not expose HWCR.TscFreqSel to guests

[Jan Beulich <jbeulich@suse.com>]

On 13.09.2023 16:52, Roger Pau Monne wrote:
> OpenBSD 7.3 will unconditionally access HWCR if the TSC is reported as
> Invariant, and it will then attempt to also unconditionally access PSTATE0 if
> HWCR.TscFreqSel is set (currently the case on Xen).
> 
> The relation between HWCR.TscFreqSel and PSTATE0 is not clearly written down in
> the PPR, but it's natural for OSes to attempt to fetch the P0 frequency if the
> TSC increments at the P0 frequency.
> 
> Exposing PSTATEn (PSTATE0 at least) with all zeroes is not a suitable solution
> because the PstateEn bit is read-write, and OSes could legitimately attempt to
> set PstateEn=1 which Xen couldn't handle.
> 
> In order to fix expose an empty HWCR, which is an architectural MSR and so must
> be accessible.
> 
> Note it was not safe to expose the TscFreqSel bit because it is not
> architectural, and could change meaning between models.

This imo wants (or even needs) extending to address the aspect of then
exposing, on newer families, a r/o bit with the wrong value.

> Reported-by: Solène Rapenne <solene@openbsd.org>
> Link: https://github.com/QubesOS/qubes-issues/issues/8502
> Fixes: 14b95b3b8546 ('x86/AMD: expose HWCR.TscFreqSel to guests')
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

As mentioned before, with this Fixes: tag I think the description
absolutely needs to mention the (changed) view on the Linux log message
that had triggered the original change. It certainly helps here that
Thomas has already signaled agreement to a Linux side change.

Jan