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

Re: [PATCH 1/3] Revert "x86/msr: drop compatibility #GP handling in guest_{rd,wr}msr()"


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Wed, 17 Mar 2021 09:40:42 +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=hFyGBI/eiR7KrWqWCdQTtNC4YUgmYVqHlxSKYFtdePA=; b=Mbfee2XNnk62Peup5hY2UhQz282NnQxcA6dIXwOqyyPFloltc4Mxo+q0l8GbqkZZ2F9CutSx5C7MBEnnvjTiVqFaM5tZNVAH+tu+NPFdgm5CfD74oRET7fX1E0yPOp2o1oEQeIMnTVoTMk34u/HujcOmc65aXwLnljag1lJjlLh5ggYK1kILuYQar1ysAyMwk8wdI9MsfXlnqzPG5lKofkgFwv2GX47Z3Xk6ZiOxGY8ryVGNwOstUZcKL2XnH4EoLSZvoX4sdqh6Lo0kapeeon3u7kLSmYBDHzcAwItKNVKClG5fGaAyjDCbmbN2Juy41lvdi/VMuIHzfpPXa4tUUg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DJm0zpJiTGp633nyEHPZiPyLq5H4BuzxIpDTgN85Wt8m4FOVS35LTG74/uv7uqh5Cu+zRjTnOe4m2istjO1yG3qL24clb+0Ps1GVly7OAkDkCqq0U2Pw5Eg9ACHVMAYPHfNChHA6AprDuJYT4iZxA2KCQlAkIEmGfUTVFxHjsspMj4mPCnzBDLTg+o5x93NxVMxsKp2U6LxVMkqeOjzfzu41P5s/5hZhNzB4K5q1Lt9T4i4PTt8TBIVgq1xTQNWQhCtuLoFPTQsofEW5s92LPbHfy+TZX8okIMLMxWzAwwALmebfhm/rq5tTpXNqQ8r5/KKWUf/IMj9e2umkUjGP2Q==
  • Authentication-results: esa2.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxx>, Wei Liu <wl@xxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>
  • Delivery-date: Wed, 17 Mar 2021 08:41:20 +0000
  • Ironport-hdrordr: A9a23:zP9yHqzXciinHuQnE3e3KrPxve4kLtp033Aq2lEZdDV8Sebdv9 yynfgdyB//gCsQXnZlotybJKycWxrnmqJdybI6eZOvRhPvtmftFoFt6oP+3ybtcheTysd07o 0lSaR3DbTLYGRSpdrm4QW+DtYryMSG9qftvuvF03JxV2hRCp1IxS0RMHf9LmRdQg5aCZ0lUL ed/NNAvTq8eXIRB/7LfEUtde7FutHNidbacQcLbiRXkzWmoBGJzPrBExae1goDSD8n+9kf2E XMjgCR3NTAj9iV0RnZvlWjiqh+uNyk8ddbAdzJt859EESQti+NRKBMH4KPpyo0pubH0idarP Dprw07N8p+r1P9F1vF2CfF4AXr3DYw53KK8zbx6hGC0K+JNw4SMMZPiZlUdRHU8SMbzalB+Z lGwn6DsN5vBQ7A9R6NmeTgbQ1glUa/vBMZ4IgupkFYOLFuDIN5nMg0+UNYF4o4ByTq6IwrO/ kGNrCi2N9mNXyddHzXpW9p3ZiFWWkyBA6PRgw4ttWSyCU+pgE182IogOgk2lsQ/pM0TJdJo8 zCL6RTjblLCusbd7h0CustSda+Y1a9DS7kASa3GxDKBasHM3XCp9rc+7Mu/tynf5QO0d8bhI nBeEkwjx9yR2veTem1mLFb+BHER2uwGR73zNtF2pR/srrgAJL2LCy4Tkw0mcfImYRQPuTrH9 KIfL5GCf7qKmXjXaxT2RflZpVUIX4CFOIPvNIWXE+Pv9LrJoXmuvezSoeRGJPdVRIfHk/vCH oKWzb+YO9a6FqwZ3P+iB/NH1PhE3aPv65YIez/xaw+2YINPopDvkw+klKi/PyGLjVEr+gTdE t6K7X3r7OjqQCNjCP1xlQsHiAYIlde4b3mXX8PjxQNKVnIfbEKvMjaXmxOwn2dJFtaQ9nNGA BS43R7kJjHYKC49GQHMZaKI2iah3wcqDahVJEHgJCO4s/jZ9cfFZYpWKt4EC3RDBxrkQNWqG NOATV0BnP3J3fLs+GInZYUDObQe51XmwGwO/NZrnrZqAGhv801f2AaWDSvSMaTpg4rS1Nv9x lM2p5apIDFtSekKGM5juh9FFFXcmyYDIhLCxm/aJxOlqrmfxxxSmm2lSWX4itDClbCxgE3vC jMPCeUcfbEDh5mtndU3r3D3Xl0em+eFngAIkxSgMlYLyDrq3xz2eiEau6PyGOXcEIF2fxYGi rCeyEuLgRnwM2X2BaZlC2ZL2gvwowjM4XmffMeWoCW/knoBJyDlKkAEfMRwY1sM8r2tPQXFc 2YYA2YIVrDepQU8j3QgkxgHiZ6qHMpy6y1nDLk6XW1x345D775Jk98S7QSPtGb6CzFSp+zoe BEpONwmdH1FGP7LuOi4+XwSRVoLxvIu264T+0ys/lvzOsPnYo2O6OeaCfC0XFM4Q43I8j1nn 4PWagT2sGyBqZfO+gpPx9D9lUnlN6zPFImnwz/DOg5Z0wshRbgTqe0youNjbokGUuaogTsfX GZ7i1G5v/ANhHznoIyOuYVIW5MblI752kn1OSed5fIAAHvU+1Y5lK1Pjucd7BaIZL1U4k4n1 Jf49uSmfWQeDe98AfMvSFjKqYLyl2Ze6qJcXSxMN8N1ce7N1SKirar58D2rA6fc0rGV20owa tfdUIRacxfjCIFl4Nf6Fn1dpDK
  • Ironport-sdr: cD8GqvqOqlwgKcg83JCp1iIizneX98ZRZq6hqW/Fr81Y0Busdf5z0piajlzhaipb7vBFNlt7NP vn9xi1Hj/wB80i/6dYU/33gATduD7f7iyusKUabD/rmstrUVB8fs1f6Gg5eV/+hrVSeXyrq8JU E7tWUMyBUCjqb8sauYfXt9VP9eDQLK5oiq0aQbPuCMjGh7Q0Xd7q1o34bXVv4Oq2rweS5/xErH nHAGkS+3aZFdmBC2Zoqbt1193uUPpLi4JwPQewMd9qXc+rRlmyd1Lv24G619BdLMmuG4p37uXu 0DI=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Tue, Mar 16, 2021 at 04:18:42PM +0000, Andrew Cooper wrote:
> In hindsight, this was a poor move.  Some of these MSRs require probing for,
> causing unhelpful spew into xl dmesg, as well as spew from unit tests
> explicitly checking behaviour.
> 
> This restores behaviour close to that of Xen 4.14.

I think it might be worth adding that guest access to those MSRs will
now always trigger a #GP, even when msr_relaxed is used. This is
however fine, as that's not a regression when compared to older Xen
versions, where access to the MSRs also trigger a #GP
unconditionally.

I assume the wrmsr side is added so that when using msr_relaxed Xen
also injects a #GP for writes to those MSRs, as it would do for
reads?

Thanks, Roger.



 


Rackspace

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