Avi Kivity wrote: >> >>> 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.
Okay, that makes sense. > Entry into SMM will issue an ioctl() to remove the vga routing; exit > from SMM will reinstall it. Right. >> 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? I was hoping to be able to do this with something like CPUID but there isn't a bit. Right now I'm using PIO but I'd have to ask on the bochs mailing list whether or not this is a reasonable thing to do. The current bochs bios doesn't really do anything with SMM. It merely enables or disables ACPI. Regards, Anthony Liguori > >>> >>>> 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. > ------------------------------------------------------------------------- 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 _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
