From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: XENMAPSPACE_vlapic vs XENMAPSPACE_vlapic_compat Date: Wed, 2 Oct 2013 00:29:11 +0100 Message-ID: <524B5AC7.5070002@citrix.com> References: <6035A0D088A63A46850C3988ED045A4B66597E25@BITCOM1.int.sbss.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <6035A0D088A63A46850C3988ED045A4B66597E25@BITCOM1.int.sbss.com.au> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: James Harper Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 01/10/2013 23:39, James Harper wrote: > GPLPV tries to map vlapic for TPR acceleration. Under what circumstances/versions are XENMAPSPACE_vlapic and XENMAPSPACE_vlapic_compat supported or not supported? > > Thanks > > James Short answer: not at all. Long answer: will continue to work on XenServer for the forseeable future for compatibility with our older windows drivers. Both of them were gross XenServer hacks to solve the WinXP TPR performance problem on hardware without vTPR, and never upstreamed. XENMAPSPACE_vlapic_compat (defined as 3) became a binary incompatibility with Xen 4.2 with the introduction of XENMAPSPACE_gmfn_range XENMAPSPACE_vlapic (defined as 0x80000000) is luckily a long way away from being a binary incompatibility. With the lapic fastpath in commit 5d43891bf4002b754cd90d83e91d9190e8c8b9d0, there is less of a need for the vlapic mapping anyway. Furthermore, allowing a guest a RW mapping of its own hypervisor vlapic page is a hard sell for the security concious, although I did spend quite a long time investigating the possible vulnerabilities and came to the conclusion that the worst a guest could do was monkey with its own interrupt injection. As these are just performance tweaks for WinXP (which is almost out of extended support) on older hardware only, there are no plans to upstream the patches. ~Andrew