On Tue, Aug 5, 2008 at 5:09 PM, Daniel Godás <[EMAIL PROTECTED]> wrote: > Yep, im actually writing an io emulator that could substitute qemu. My > intention is to make virtual device development easy enough to keep up > with the evolution of real hardware. Many real devices can remap their > io ranges (this is always the case with northbridge chips) and that is > something the cannot be correctly replicated with the current memory > management infrastructure. Qemu has many ugly workarounds to get over > this (it basically assumes the mappings are static). >
Fair, but why can't you live with an extra slot? In the case you showed, it seems to me that it would be perfectly fine to poke a hole in the middle of the address space, and when we need to use this address again, just grab a new slot number and go with it. Also, note that register_slot is a tracking facility. The real thing is registering a slot within the kernel. For the case in which we poked a hole and are now giving this portion back, we can live with the same userspace addr. But for other cases, coalescing might be harder, since we won't have a contiguous userspace addr. > 2008/8/5 Glauber Costa <[EMAIL PROTECTED]>: >> On Tue, Aug 5, 2008 at 4:41 PM, Daniel Godás <[EMAIL PROTECTED]> wrote: >>> Hi, >>> >>> i've playing with libkvm.c and tried to make register_slot a bit more >>> intelligent. The code in the repository always creates a new slot when >>> register_slot is called but to give memory management more flexibility >>> it could detect adjacent slots and merge them automatically. I attach >>> a patch that illustrates what i want to do. With something like this >>> implemented in kernel space too, memory management could be made much >>> more flexible as memory holes could be created and modified on the >>> run. >> >> Hi >> >> Right now, I'm trying to completely rewrite the memory registration >> (if needed), to reduce >> the impact of kvm specific code in qemu. Do you have any specific use >> case that led you to >> this patch ? >> >>> >>> Sample scenario: >>> >>> 1) kvm_create_phys_mem creates a big memory chunk >>> 2) kvm_create_mem_hole makes a hole that will redirect accesses to io >>> emulation (starting at userspace address ADDR) >>> 3) kvm_register_userspace_phys_ >>> mem re-registers the hole as user memory by passing it a pointer to ADDR >>> >>> The patch will not work by its own without more changes, its just for >>> illustrative purposes. >>> >>> Cheers !!! >>> >> >> >> >> -- >> Glauber Costa. >> "Free as in Freedom" >> http://glommer.net >> >> "The less confident you are, the more serious you have to act." >> > -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act." -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
