[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] x86/SVM: restrict hardware SSBD update upon guest VIRT_SPEC_CTRL write
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Mon, 12 Dec 2022 12:06:16 +0100
- 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=nH75FYLfPiOxaL47gxLeYgzQek1JJcB0xRcFV97EqyU=; b=O4mSw4qs+Jqy8YE9QXEEAMZ4IYoJs0w448yoySASQQWJvtiPKltSfJdUPX+LMMHKga9K7jJNY/C05yf9uMGuyEoB3dUbDtP2GcwXNSYDFgFONu6wv8WDNKDZljYwrUUkViM9VZktBUzdacQtFCASL1RPosInMn5tt3S4Ovbf6Hcavu9aE6PeV5J26zAcx+GPmS8UZjHQuCJVqI1WHg1SPcDfko2m6AiHDYKEsnObKe+ugxo3Axp1h0TRPI1fzjGWiAsWYPpU+qG+QsCFX5PCVcgi748JYXcRmFTJiLlaGSNkGOVAElZa5sDs8e29eJojUYrfSWK1ehvYwEYjGf2M/g==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jRWSXiu2UdnYNz+bjxUnE8wUWBlIwC1ROt+ibEU/dHJnaqDjlk1uJRi137wPpl5HTdPVRP/Wq09oUFhioWE9VOvX1FM0KQoXxPhQzHsYJ2HKyhgT1uDY9icXTmbrsF88besZLDNclri4Sws794GTEaCUlzXpNddwD0ot5lu7ST4m8Q69m9hozM302X3pzKGvM6DTcjegrFF4iW7swQrs9hKOUyoGPDfnOlIxW242O+nfcwcWZwaMPQnqlueXYa1zq/M5bqfAePJ32BTEMPzVbx91tu5TIP8mSCeZDqSx+PJ97IqhbaakXWSXA5AgL+Nua5OLnUaEN3o05YqZeQzV9Q==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
- Delivery-date: Mon, 12 Dec 2022 11:07:34 +0000
- Ironport-data: A9a23:YswKdaoVwHWfPOE13ohSLAsjb0NeBmI+ZBIvgKrLsJaIsI4StFCzt garIBmFa/eCN2vzfIt2YIrg9kwDvpaEm9VrGwM/pX8yRn8a8puZCYyVIHmrMnLJJKUvbq7FA +Y2MYCccZ9uHhcwgj/3b9ANeFEljfngqoLUUbKCYWYpAFc+E0/NsDo788YhmIlknNOlNA2Ev NL2sqX3NUSsnjV5KQr40YrawP9UlKm06W1wUmAWP6gR5gaEziNNVfrzGInqR5fGatgMdgKFb 76rIIGRpgvx4xorA9W5pbf3GmVirmn6ZFXmZtJ+AsBOszAazsAA+v9T2Mk0MC+7vw6hjdFpo OihgLTrIesf0g8gr8xGO/VQO3kW0aSrY9YrK1Dn2SCY5xWun3cBX5yCpaz5VGEV0r8fPI1Ay RAXAGoTP0+ZqN3n+Z+EDdA9jJgiIJnILrpK7xmMzRmBZRonabbqZvyToPN9gnI3jM0IGuvCb c0EbzYpdA7HfxBEJlYQDtQ5gfusgX78NTZfrTp5p4JuuzSVkFM3jeeraYWOEjCJbZw9ckKwv GXJ8n6/GhgHHNee1SCE4jSngeqncSbTCdpJSuPnq6MCbFu75j0DCjQwCwWCmfi3kEKkZ4x4D mUQw397xUQ13AnxJjXnZDW6qnOZuh8XW/JLDvY3rgqKz8L88wufQ2QJUDNFQNgnr9MtAywn0 EeTmNHkDiApt6eaIVqC8p+EoDX0PjIaRVLufgcBRAoBptXm/oc6i0uWSs45SfHuyNroBTv33 jaG6jAkgKkehtIK0KP9+k3bhzWrpd7CSQtdChjrY19JJzhRPOaND7FEI3CBvJ6s8K7xooG9g UU5
- Ironport-hdrordr: A9a23:n/4gPK/RuS0LogzJHBRuk+DrI+orL9Y04lQ7vn2ZKCYlFvBw8v rE8MjzuiWbtN98YhEdcKm7Sc+9qBDnhPtICOsqUotKNTOO0AGVxedZnOjfKlXbdhEWndQ96U 4PSdkdNDX6ZWIK6vrS0U2dN5IBzbC8gdmVbJ/lvg9QcT0=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Fri, Dec 09, 2022 at 11:11:29AM +0100, Jan Beulich wrote:
> On 09.12.2022 10:59, Roger Pau Monné wrote:
> > On Thu, Dec 08, 2022 at 12:24:54PM +0100, Jan Beulich wrote:
> >> --- a/xen/arch/x86/msr.c
> >> +++ b/xen/arch/x86/msr.c
> >> @@ -699,12 +699,16 @@ int guest_wrmsr(struct vcpu *v, uint32_t
> >> }
> >> else
> >
> > I think you could turn this into an `else if` and check if the new
> > value and the current one differ on the SSBD bit?
>
> I'd prefer not to: Keeping it as I have it will likely reduce code churn
> if a 2nd bit wants supporting in that MSR.
>
> > Provided it fixes the issue:
> >
> > Acked-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>
> Thanks, but I'm a little puzzled by the constraint: Imo even if this
> doesn't address the observed issue, it still fixes one aspect of wrong
> behavior here. The sole difference then would be that the Reported-by:
> would go away.
Just wanted to make sure whether there was a further issue linked with
this, in a way that we might need to change the fix. Maybe do the
accounting in amd_set_legacy_ssbd() and keep track of each thread
status.
Thanks, Roger.
|
