From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: x2APIC MSR range (XSA-108 follow-up) Date: Thu, 16 Oct 2014 10:56:01 +0100 Message-ID: <543F9631.7020700@citrix.com> References: <543B9146020000780003E14D@mail.emea.novell.com> <20141013105743.GA10775@u109add4315675089e695.ant.amazon.com> <20141016075706.GA20604@u109add4315675089e695.ant.amazon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xehmx-0005N1-Vi for xen-devel@lists.xenproject.org; Thu, 16 Oct 2014 09:56:08 +0000 In-Reply-To: <20141016075706.GA20604@u109add4315675089e695.ant.amazon.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: Matt Wilson , "Zhang, Yang Z" Cc: "Tian, Kevin" , "Wu, Feng" , Jan Beulich , "Dong, Eddie" , "Dugger, Donald D" , "Nakajima, Jun" , xen-devel List-Id: xen-devel@lists.xenproject.org On 16/10/14 08:57, Matt Wilson wrote: > On Tue, Oct 14, 2014 at 06:23:52AM +0000, Zhang, Yang Z wrote: >> Wu, Feng wrote on 2014-10-14: >>> The SDM 10.12.1.2 says: >>> >>> " Addresses in the range 800H=A8CBFFH that are not listed in Table 10-6 >>> (including 80EH and 831H) are reserved. >>> Executions of RDMSR and WRMSR that attempt to access such addresses >>> cause general-protection exceptions. " >>> >>> Table 10-6. Local APIC Register Address Map Supported by x2APIC >>> >>> Why should we virtualize those reserved MSRs for guests? >> IIUC the question should be why those undocumented MSRs exist on >> real hardware and what do they do? Will guest access to them via >> check CPU model? If yes, how can we virtualize them correctly? > I suspect that Intel knows what they are and what they do. I imagine > that both are CPU model specific. > >> I don't have the answer right now but I will forward the question to >> hardware guy for more help. > Since these MSRs are not part of the SDM or any public platform > documentation as far as I can tell, I imagine that they are for > BIOS-level functionality that does not have meaning in a virtual > environment today and presents no OS compatibility problem if we > choose to #GP all access to them. > > Short of some reply from Intel saying "No! That will break some OS" I > think that we should make the x2APIC MSR code handle 0x800...0xbff and > #GP any access that is above the emulated area. I have a patch like this currently getting a kicking in our dedicated XSA-108 test set. I will report back with how it does. ~Andrew