Andrea Arcangeli wrote: > On Tue, Apr 01, 2008 at 01:21:37PM -0500, Anthony Liguori wrote: > >> return a page, not a HPA. I haven't looked too deeply yet, but my >> suspicion is that to properly support mapping in VM_IO pages will require >> some general refactoring since we always assume that a struct page exists >> for any HPA. >> > > Yes, that was potentially problem for reserved _ram_ pages too, as it > isn't guaranteed that memmap_t (old days nomenclature) will exist for > physical addresses not defined as ram in the e820 map (to make it work > without VT-d I have to reserve the ram in the host at the e820 map > parsing time). If the memmap will not exist for the reserved ram > physical range, the pfn_valid() will fail at runtime in kvm and the > bad_page will generate a graceful emulation failure, so it's very > safe. But once we handle direct memslots for mmio regions, the > reserved ram will better stop depending on the memmap too. >
Direct memslots is quite a sledgehammer though to deal with IO pages. You could get away with supporting reserved RAM another way though. If we refactored the MMU to use hfn_t instead of struct page, you would then need a mechanism to mmap() reserved ram into userspace (similar to ioremap I guess). In fact, you may be able to just lie and claim reserved ram is IO ram. Then we could treat the reserved ram in the same way as IO ram and not have to introduce a new interface in KVM for mapping arbitrary regions of memory. I would be interested in this sort of mechanism not for reserving low RAM, but for reserving high RAM. Basically, I'd like to boot with mem= something and then still be able to map the higher memory in QEMU userspace and then create KVM guests with it. Regards, Anthony Liguori ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
