[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] x86/amd: do not expose HWCR.TscFreqSel to guests
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Thu, 14 Sep 2023 14:37:59 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gWrB9Pq/42EEw2thATh68/NsnMyZa1vXuDE5bccAiK0=; b=L61/6GC/nlP0JcLiwbn8CBGdVyOVc7LAoPtOjaPE2vn7uciGFKGSXeDv5/nReD5efZjmUqOk4sScKIGSAX213mLTCXHfN7mozKlPj85RlZliNoGmLOdohc/tfgPolD1KZdXv2QkAnntzxo/qEtrCpAKJNruEMiBU/z7eoyR5aC3i9HBwNupRGgXCVBqMRdc8svzVCZhKDVG96kulunfuQk58slNdvnmLPoW4124iLrD9w5nKZRGmRwvxe8HqstgKl09hij4T5eJjr3CWhmCEy+PRWZEpPklLozEe3nU51/Aagzfuxvj8UXD1COquCUjs0xpcW7o5RAhwaEHapiO8Jw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=THW3iykrK2Gzr0LUeecWY9AjRLUVO0QPHBp1NKFKwwandZnsR4xH2GsvZGL4wQO+Ag5wiGGD7E6hMAPQynmCWoT7gl3DfrRYZsjRv1A9nnuDgsN3PDb6KOrrwkDNBHkYqebBb6fTGM6LhnrNDHl92ay1w0XMxMvfantdpwP/wJwFUfBBgc6BlcuReDTJ23fDWxrS8cWwYqmmEvPSNLkerguykzheq5gQM19g2rCDNUCIxb+10oGOf78TeixHPuATeSFrwDCkTnzm3B+WbVA8aG7DpSKj1DRY4IxzMzeqijdRO2vRDMt+k4J+VGkkI7TH0h3kTVEdTaXTW/URcqVhRA==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Solène Rapenne <solene@xxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Thu, 14 Sep 2023 12:38:28 +0000
- Ironport-data: A9a23:hj9zCK/0h3wcUrPC88HQDrUDsn+TJUtcMsCJ2f8bNWPcYEJGY0x3y GsWDW7VPP6KZ2b1L95zaY3l908E6pbcxtZnS1M5/C88E34SpcT7XtnIdU2Y0wF+jCHgZBk+s 5hBMImowOQcFCK0SsKFa+C5xZVE/fjVAOK6UKidYnwZqTZMEE8JkQhkl/MynrlmiN24BxLlk d7pqojUNUTNNwRcawr40Ird7ks11BjOkGlA5AdmNKkX5AS2e0Q9V/rzG4ngdxMUfaEMdgKKb 76r5K20+Grf4yAsBruN+losWhRXKlJ6FVHmZkt+A8BOsDAbzsAB+v9T2M4nQVVWk120c+VZk 72hg3ASpTABZcUgkMxFO/VR/roX0aduoNcrKlDn2SCfItGvn9IBDJyCAWlvVbD09NqbDklh9 MI1dz0BdyzapOvq37SLbdZsmMs8eZyD0IM34hmMzBn/JNN/GNXoZPyP4tVVmjAtmspJAPDSI dIDbiZiZwjBZBsJPUoLDJU5n6GjgXyXnz9w8QrJ4/ZopTWNilUuidABM/KMEjCObd9SkUuC4 HrP4kzyAw0ANczZwj2Amp6prraVwHimA95OTtVU8NZDuWDU33YhIydIcnuxsPKzyWiUHMNQf hl8Fi0G6PJaGFaQZtv3UgC8oXWElgUBQNcWGOo/gCmSzoLE7gDfAXILJhZab9grssIeQiQn0 FWSk5XuHzMHmK2YTzeR+6mZqRu2ODMJNikSaCkcVwwH7tL/5oYpgXryos1LFae0ipj+Hmj2y jXT9Swm3exM1IgMyrmx+k3Bj3S0vJ/VQwUp5wLRGGW48gd+Y43jbIutgbTG0ct9wE+iZgHpl BA5dwK2tYji0bnlePSxfdgw
- Ironport-hdrordr: A9a23:+35ts6wvB9+4w07XApmQKrPwB71zdoMgy1knxilNoH1uA6mlfq WV9pkmPHDP5Ar5NEtOpTn4Atj4fZq+z+8W3WByB9eftWDd0QOVxedZg7cKqAeQeBEWmNQ96U 5WSdkbNDShNzNHZB7BkXKF+gwbsb+6GX2T9IDjJqtWPHlXgn9bnn1ENjo=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Thu, Sep 14, 2023 at 07:52:33AM +0200, Jan Beulich wrote:
> 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.
We could always be exposing bits with the wrong values on newer
(unreleased?) families, I'm not sure why it needs explicit mentioning
here.
> > Reported-by: Solène Rapenne <solene@xxxxxxxxxxx>
> > 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@xxxxxxxxxx>
>
> 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.
Sure, what about:
"The motivation for exposing HWCR.TscFreqSel was to avoid warning
messages from Linux. It has been agreed that Linux should be changed
instead to not complaint about missing HWCR.TscFreqSel when running
virtualized."
Thanks, Roger.
|
