From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC] Porting KVM to QEMU CVS Date: Thu, 21 Dec 2006 10:36:34 +0200 Message-ID: <458A4792.1000309@qumranet.com> References: <45861F9D.7070006@cs.utexas.edu> <45864E67.3050803@qumranet.com> <458A07C3.3080000@cs.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Return-path: To: Anthony Liguori In-Reply-To: <458A07C3.3080000-NZpS4cJIG2HvQtjrzfazuQ@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Anthony Liguori wrote: > Avi Kivity wrote: >> Anthony Liguori wrote: >>> Any thoughts? >> >> SMM continues the tradition of making each x86 generation hackier >> than before. >> >> What happens (probably) is that the virtual hardware unmaps the vga >> memory when SMM is entered, and uses the physical memory at these >> addresses (which is not normally accessible) to store the SMI handler >> code. > > Doh! SMM uses the VGA memory doesn't it. Now it all makes sense :-) That last sentence is rarely heard in the context of PC architecture. > > If I disable SMM in the Bochs BIOS, the patch works quite happily with > the latest CVS. I've attached the patch for reference. > >> The way to fix this (again, probably) is to: >> >> 1. Revert the 0-640K/1MB-end-of-memory slot thing and create just one >> memory slot for all physical RAM. > > We lose the VGA optimization here right? No. The vga optimization is that access to the pci framebuffer (which is at a runtime-determined address, but not the vga hole) is through direct access rather than mmio. The code in cirrus.c that creates the framebuffer as a kvm memory slot is thy key to that optimization. > >> 2. Add hacks in the memory slot code to not return a memory slot if >> the physical address is in the forbidden range. > > I'm not sure I understand what you mean by this. I guess I have to > spend some time and understand how the whole memory slot thing works. Memory slots are just like the DIMM (or, since the qemu model is rather old, SIMM) slots in a PC. A PC memory controller has circuitry to route memory access to a DIMM or to the PCI bus. The logic is something like this (first match wins): - if the access is to the VGA hole, and we're not in SMM, route the access to PCI (the vga controller will route it further to somewhere in the framebuffer) - if the access is to the VGA hole, and we are in SMM mode, route to the DIMM that contains the address - if the access is to the ROM areas (0xf0000-0xfffff), route to the ROM - if the access is to an area mapped by a DIMM, do that - otherwise it's an mmio access My proposal is to implement the special runtime routing table. This way we can have a DIMM that covers all of memory including the forbidden hole. Entry into SMM will issue an ioctl() to remove the vga routing; exit from SMM will reinstall it. > >> 3. Add another hack to disable the first hack when SMM is entered and >> re-enabled it when SMM is exited (e.g. some ioctl). > > I'll have to read a little more into SMM. It can be entered at any > moment right? yes. > I seem to recall that either the VT or SVM spec has special handling > for SMIs? At least VT. It's horribly complex. It's meant more for the host rather than the guest. > > Another option to consider would simply be to have the BIOS detect > whether or not the emulated hardware supports SMM dynamically (right > now, it's a compile time switch). This would let us turn it off in > QEMU when KVM is enabled. > That may be best. What does SMM buy us anyway? >> >>> Is anyone else working on this? >> >> I intended to merge qemu once a release is made. However, if you get >> this working and it is stable, it may make sense to merge sooner as I >> very much like qemu cvs. > > I would rather just submit this patch (with the BIOS hack) to QEMU and > try and get it picked up in CVS. There are some regressions at the > moment in CVS so it may be nice for users to have an 0.8.2 based > version available. What do you think? > > Would be nice to have KVM support in QEMU CVS by the time 2.6.20 rolls > out. I'll reply to this in the next email, this one's too long already. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV