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

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


  • To: Ian Jackson <iwj@xxxxxxxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 1 Mar 2021 18:52:02 +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=+vO6ge7pGSUMm0wQHeGn2y/o0F5PADTZi596ljeQehg=; b=CBGoX7L3rb4/W36upR+7b5G4vySVsyV48JewgsVqsuWhq0uSO9Olx505KN52NERN4A4aZibRcmmfyiP4kiUFdYHq0iPXnBLldZMg2IJUbLNs8sEpcoVDuWYF2NwpnL4aD7axbf38DNihDTQfPgedaIPjoCDV9p7id/yOXq1r3SjgNHbNG+sh2riVw4a68vHR9Xpkn9z7OHEzN6DvJVpH4H/hjQx9SelVC/vwuot7qWBOsc6hQ8h5RXbnmUnY1o37VU76XgfgKASNlDy5d6r/IAXQmvIapoi3V2cqSoI3CfJ6X5SCvzBEsMdRhi6AXiWp+GdbQ1ywtYkmiHIoSvCHgg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GYp5REqLBxXGBNlci4MDrHTaY+zh+fl/BscA5MrYJj6NjoUBupA71oMRFWdx2Fkz7vuoyTbK4F8o5nfhqpwqnRV6t0odO0B1aAyaTBn/QjJxpFVoH5NS8wagVWjMpJQ6W7lj8sSgFLaQ90UofrYOOvpi39+HdRMPoy3eImMN2PdNBYXcqwD0m3AuXbOAo3O5k7hdcVveFTDQueiofTjWr16LepmdYDokjv0cUxX5bbxZ+0q+c1gLwNIk2DvpbTyT53UY/GAlZ1X0Ex7o8GQN5pHrSdjbfeXVNeNH50h2wLYv7vyQPp/2fja1LnPjsXCiOPrEcmcP/GhSDLtvICvdkQ==
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
  • Delivery-date: Mon, 01 Mar 2021 17:52:15 +0000
  • Ironport-sdr: AsyBMN6QSkhSGzmL8LJDNrCe06uCBmzwnwZLeW6y5UDKaMoYE8Ep7Gf3k5wpTLRUjFh4ZIleRG A23q6Y0tVOVTvaF81kb0D5qTTXQ7Y5/xus1yEvugdedrskpzPimFLlcmn5a/lLy6w7dwq+keXX 0Js3GtBlkoOQqb5ksbAJIpo5RB7+Df6gDx6XaJa/cMViHhsB6DCt6HIab7k6jie7Yxt5GTjswe VzCDzGYYEK6nP6X0PViY3SlDIjIJ52wq+2HRQmI387zaY06A9p0+462uuLzERRTaFuPbNJRimV hmg=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Mon, Mar 01, 2021 at 05:16:34PM +0000, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH RFC for-4.15] x86/msr: introduce an option 
> for legacy MSR behavior selection"):
> > Introduce an option to allow selecting the legacy behavior for
> > accesses to MSRs not explicitly handled. Since commit
> > 84e848fd7a162f669 and 322ec7c89f6640e accesses to MSRs not explicitly
> > handled by Xen result in the injection of a #GP to the guest. This is
> > a behavior change since previously a #GP was only injected if
> > accessing the MSR on the real hardware will also trigger a #GP.
> > 
> > This seems to be problematic for some guests, so introduce an option
> > to fallback to this legacy behavior. The main difference between what
> > was previously done is that the hardware MSR value is not leaked to
> > the guests on reads.
> > 
> > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> > ---
> > Cc: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
> > ---
> > Note that this option is not made available to dom0. I'm not sure
> > whether it makes sense to do so, since anyone updating Xen to such
> > newer version will also likely pair it with a newish kernel that
> > doesn't require such workarounds.
> > 
> > RFC because there's still some debate as to how we should solve the
> > MSR issue, this is one possible way, but IMO we need to make a
> > decision soon-ish because of the release timeline.
> > 
> > Boris, could you please test with Solaris to see if this fixes the
> > issue?
> 
> So AIUI this patch is to make it possible for Xen 4.15 to behave like
> Xen 4.14, thus avoiding a regression for these troublesome guests.

Yes, sorry I haven't provided a release executive summary, as I wasn't
sure this would be acceptable in it's current form. Can do if there's
consensus this is an acceptable fix.

> Have we diffed the result of this against 4.14 and if not would it be
> a sensible thing to do ?

I think there will likely bee too much noise, we have changed the MSR
handling a bit from 4.14, so it's likely a diff to 4.14 is not going
to be helpful as the context will have too many changes (albeit I
haven't tried the exercise myself).

Thanks, Roger.



 


Rackspace

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