From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Supporting default reads of host MSRs [WAS: x2APIC MSR range (XSA-108 follow-up)] Date: Mon, 13 Oct 2014 10:52:34 +0100 Message-ID: <543BA0E2.5030904@citrix.com> References: <543B9146020000780003E14D@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XdcIy-0000fm-CO for xen-devel@lists.xenproject.org; Mon, 13 Oct 2014 09:52:40 +0000 In-Reply-To: <543B9146020000780003E14D@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Eddie Dong , Jun Nakajima , Kevin Tian Cc: Matt Wilson , Donald D Dugger , xen-devel List-Id: xen-devel@lists.xenproject.org On 13/10/14 07:45, Jan Beulich wrote: > All, > > during the embargo period of XSA-108 Matt pointed out that restricting > the emulated MSR range to 0x800-0x8ff isn't necessarily the ultimately > correct thing to do (as also noted in commit 61fdda7acf's description): > The x2APIC MSR range really is being specified as 0x800-0xbff, as > opposed to the range considered for virtualization purposes > (0x800-0x8ff). In order to determine proper behavior here we'd like to > get clarification from you, particularly also in the light of probing real > hardware pointing out the existence of (at least) MSRs 0xa00-0xa02. > > With what we currently do (kind of supported by their values at least > not differing across physical CPUs on the probed systems) their values > are getting passed through to guests. The alternative of forcing #GP > for accesses to them as one could imply from the spec seems > undesirable: Guests may imply their existence based on CPU model. > Hence the only apparent reasonable alternative would be to provide > proper virtualization for these registers, requiring to know their > purpose. > > Thanks, Jan Having read this and put two and two together, permitting default reads of host MSRs is irreconcilable against correctly supporting migration of HVM VMs. In the past, XenServer has seen a handful of cases of a Window BSODs because of critical structure corruption in the IA32_MISC_ENABLE MSR. They were unable to be seen again, but were on migration tests. Exactly the same logic applies to the cpuid infrastructure, although that has many more noticeable problems atm. ~Andrew