From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Patch] Qemu map cache Date: Tue, 05 Dec 2006 14:48:09 -0600 Message-ID: <4575DB09.7000105@linux.vnet.ibm.com> References: <666CC8FCE3247C4DA876BA979059781A5C27DD@pdsmsx401.ccr.corp.intel.com> <4574A813.5050402@linux.vnet.ibm.com> <8A87A9A84C201449A0C56B728ACF491E04EDB4@liverpoolst.ad.cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <8A87A9A84C201449A0C56B728ACF491E04EDB4@liverpoolst.ad.cl.cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Pratt Cc: xen-devel@lists.xensource.com, "Cui, Dexuan" List-Id: xen-devel@lists.xenproject.org Ian Pratt wrote: >> Have you considered doing something similar for mainline QEMU? The >> reason I ask is that V2E pulls in all of the dynamic translation code. >> My initial reaction is that doing map cache will require a significant >> amount change to the dynamic translation bits since we can no longer >> make the assumption that memory can be accessed directly. I don't >> > fully > >> have my head around it yet, but this may involve lots of nastiness >> > with > >> keeping track of which TB's reference what memory and invalidating >> > those > >> TBs when map cache references are invalidated. The QEMU TLB may >> simplify some of this but I'm not entirely sure. >> >> Have you given this any thought? >> > > Being able to invalidate (sections of) qemu's mappings (at least > asynchronously) is essential to allow the balloon driver to work for HVM > guests. To be able to change portions of the physical memory mapping right? You don't strictly need a map cache for this (you can simply remap portions of the address space). You really only need the map cache for > 2GB guests (which admittedly could be a ballooned down guest that started out > 2GB). > V2E is going to have to bite the bullet on this one. > > Of course, in a 64b environment the map cache can be direct mapped, but > you still need the ability to do invalidates. BTW: I'm comfortable if > V2E only works on 64b. We may be able to work around this using one of QEMU's TLB. If the map cache goes in for 3.0.4, then we can look at just supporting 64 bit for 3.0.5 and fixing 32 bit post 3.0.5 (if that's necessary). Sound like a reasonable plan? Regards, Anthony Liguori > Sooner or latter there's going to be some new > feature which isn't supported on Yonah... > > Ian >