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

Re: [PATCH v2 for-4.15] x86/msr: introduce an option for HVM relaxed rdmsr behavior


  • To: Ian Jackson <iwj@xxxxxxxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Thu, 4 Mar 2021 16:13:15 +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=AEKHg+sw75mujriAG+HiLsQ2suVIWOFFpQLooMyeiPs=; b=WPRHaWnyhaVgbkqYH6h9Q0V1bUM4vFhg1p/1ksMff5TGlLWimdIgi1x6OmR02Wf8bQnPtfrP93MUPQrWIIRujnxcTTqmtQ8uaBEsn6+ajAwH3TiueQqoPpNQ3yi5zfkyEtp+EEXwbOudVm1ggBWV47mRkanfvjgPut1O8DYzJxdU6S3HgtV/CDrlmfepsaDte2zNwfftRsijLMe+KgVzVBvFbDYd+I0t3AfC8k3IWCHfPtVB4LTyzC0X12tyAmWeNWY2Pr+KxXVyyB3+Ez3izhR1xHz/0INukzRXiZbdpP0n1BKrkJWVX4IiYJyCc2uv3U47G1oiLH3dBNBzbr0FhQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R3dfIWWWbITxt3Y5Cvh1zWX9bI4xmcaa8092C72D4RFJy22YPN/QzxQzMqd8AoDEVv36g064JKy+ILFxZaFZNppbhbwUqf9PBlg9YJfMoKc5dgd5cp9afvdM9btLjUH3oUilm1rPFlCiTIDNORlAVblzfwU6ENMkT4a4kr53P7am53FUNv9troD/Ek14BG7kRyOiiKOW5BmDQJ/wN0GIUS7J4f8BVmiX7kWgdAHhTQyKkQqJAEpkgUAag3iT98gOH0Bj5KwHLlDbvOvSpmwwZyEH0yC3ohcF7DTSraMOBSCeieLk80M/mRJB/mOs8ojP3nIB4imdfrJXRLXedho7uQ==
  • Authentication-results: esa2.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: Thu, 04 Mar 2021 15:13:39 +0000
  • Ironport-sdr: qp7zNqE4w3bNLoQzvrh7KjDMhQ7LujK2fnBnO88/QXEA10AXaGLLBvpm3wL/FQL3E4ZpqUQOPE 2wTf+X7toAc/dYCwS26BbYUM/eOnuVpCAXbAnbUBPT2Z1ZZRmACuIfTswejYN0riscfhrh3MgL NXZ5fdaotFrW65J8Bd5drNkJ8eK2mLhGamkLr9vkcFHwEvvZrRVw6tQIhE+eZ3YV4DNqmMsp2T SgYABcMmrg+71KcD8NC/UpOu46YwmaoChqWnrABLrWdgV2rgIG0FGkglN2Ks9B/STI4wb9jhGt L0Q=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Mar 04, 2021 at 02:59:38PM +0000, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH v2 for-4.15] x86/msr: introduce an option for 
> HVM relaxed rdmsr behavior"):
> > Introduce an option to allow selecting a less strict behaviour for
> > rdmsr accesses targeting a MSR not explicitly handled by Xen. Since
> > commit 84e848fd7a162f669 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.
> ...
> > I wonder whether we need to to enable this option by default for
> > guests being migrated from previous Xen versions? Maybe that's not
> > required as the option is helpful mostly for early boot I would
> > assume, afterwards an OS should already have the #GP handler setup
> > when accessing MSRs.
> 
> I think it's almost as bad to have guests which can be migrated in,
> but which then cannot reboot.

Ups, yes, right.

> Historically we have taken the view that new Xen must support old
> guests, even if that means being bug-compatible.  So I am strongly in
> favour of avoiding such a usability regression.

I'm not a xl/libxl expert, but couldn't we set the option in a
persistent way for migrated-in guests?

IIRC at domain creation libxl knows whether it's a restore or a fresh
domain, and hence we could set the option there?

The part I'm not sure is about how to make it persistent.

Thanks, Roger.



 


Rackspace

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