[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 for-4.15] x86/msr: introduce an option for compatible MSR behavior selection


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Tue, 9 Mar 2021 15:53:03 +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-SenderADCheck; bh=kAYkZH5Yy+54Ir70154BT3X2UpaA1j72GzEGOdVw/5Y=; b=k7LtgMzt76ijCMQMGyF8m3h3EKbaUlrzrTxsjCdym2idxaiiRGmnNC3YcSMeGvcvDCH4Mjcmm4smjvY8VuQ7mwYmL8ahm/8cgmouHuWh7kSdWf9jIsRnUBwEzU0sGiesIO4YZKwA8XmfNetTbGUrlXpIOzAfB/c5FQtFpxe3K24SS4gv9MEsuFV/X7bcKGavjgoFcVCd27/eH8BNJNvSuR6L+vKbr+2mskG0N4w60+/408iFcEa1HNMfHaWnVf9P8pb2p7hRZOyhLP9zcvII/EVMiGICc1oev9SgxeCaRWbv2Q9o8FPYyzwDINgsRroDrLxW/T2ckkSMXeja3CuPOg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AUVS2eKQo1Q9Nu13F00pVw7lhKmK3rgvYv8z6gQPVeLpNzxVmWCHT3gBXIsGs3baI1+wBPhik01Fwi7D4BRPcWAuXs5zpmWjx1L0xuKqcuZNvc1eMd9rwjaNCNTDWQ3lRjHAyRrjXie2jdcGQIn0vQuoHe+oPMyWB/xobKJklxqA57KS27S0JlhKn0+hmvbRCAxfYMmaYycXtrx0zmi1NgEsGYyvikgK7gnm/FCzaYh+KsOGAnyYv9gXxw0MNuyXe0wEuNlS7beJy5L60Y36qNWVziqNGQqhWZV5Gijf9aTmrWa0VJHZ9o+kwMiJtbzBXKhA1vU+AUVrr3QI7/abrQ==
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Ian Jackson <iwj@xxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Christian Lindig <christian.lindig@xxxxxxxxxx>, David Scott <dave@xxxxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 09 Mar 2021 14:53:35 +0000
  • Ironport-sdr: 4bTQ8/tKCJ6oiOCLUsM/9OX94C9uASXCc2d7/Ff2Mtbz4AsSIqUi9E9GrXAWV5jCSmoQHPrhFM Q/lHOx8cCU5Cy5snWQgDQ/y1UDjOAOHSMm+pK9+8hjZUKoWkswaOgQEn0LEtildFvbYXkoMq+M G1IkHXp6WCBZmyynquu6elA/Tb0KQxEin9lF95QNy8nzzKy+c9Ths+oS950MeCroa7nRhsA5Bu HXG2dj/sO8b0ClyLo00l5OxocduLjJHchsHoklN7sDPrUTXvghwGL63Jem8uGKZulQUrQkd1ho NJw=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Tue, Mar 09, 2021 at 03:26:07PM +0100, Jan Beulich wrote:
> On 09.03.2021 14:53, Roger Pau Monné wrote:
> > On Tue, Mar 09, 2021 at 12:36:39PM +0100, Jan Beulich wrote:
> >> On 09.03.2021 11:56, Roger Pau Monne wrote:
> >>> @@ -1148,6 +1155,9 @@ static int write_msr(unsigned int reg, uint64_t val,
> >>>          }
> >>>          /* fall through */
> >>>      default:
> >>> +        if ( currd->arch.msr_relaxed && !rdmsr_safe(reg, val) )
> >>> +            return X86EMUL_OKAY;
> >>> +
> >>>          gdprintk(XENLOG_WARNING,
> >>>                   "WRMSR 0x%08x val 0x%016"PRIx64" unimplemented\n",
> >>>                   reg, val);
> >>
> >> So what are your thoughts wrt my change to this file? Drop it
> >> altogether and require people to use this new option? Or do you
> >> see both coexist?
> > 
> > I wouldn't be opposed to have both changes co-exist, as long as the PV
> > one is made part of the PV ABI, that is have it properly described in
> > the public headers as part of the PV behavior. I've replied with some
> > details along those lines in your patch.
> > 
> >> In the latter case, since you had suggested
> >> that I drop the write side of my change - does your changing of
> >> the write path indicate you've changed your mind?
> > 
> > Yes, I think we need to provide an option to allow users to revert
> > back to an MSR behavior as close as possible to the previous one for
> > compatibility reasons, and that should include the write side even if
> > we don't know any users requiring it right now.
> > 
> > We would be in a bad position if that use-case gets discovered after
> > the release, so it's IMO best to provide an option that covers both
> > read and write side straight away.
> 
> Well, for your change it's indeed "an option". For my change it's
> not optional behavior (and we also don't mean it to be). Hence I'm
> not sure what I should read out of your reply.

Sorry, maybe my reply wasn't clear. The part of the quote above was my
reply to me re-adding the write side of the change. The reply to
whether I think your PV change is required was in the chunk above.

To clarify:

 - I do think we need the write side of this change, just for the sake
   of providing a behavior as close as possible to the previous
   release.
 - I don't have a strong opinion whether we need two options
   ({rd,wr}msr:relaxed) or just a single one (msr_relaxed). I favor
   a single one because it's likely users will enable both in tandem
   anyway (like you mentioned).
 - I'm fine with your change to PV as long as it's documented in the
   public headers as part of the PV ABI, since it will be enabled
   unconditionally (more about that in a reply [0] to your patch).
 - I think your change to PV should cover the write side also.

Hope that's less confusing.

Thanks, Roger.

[0] https://lore.kernel.org/xen-devel/YEd6GTXJqRIjijl6@Air-de-Roger/



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.