Hi folks, The following series contain a proposal for our memory registration framework. This is by no means complete, and rather, a first step only.
This first step, btw, has the goal of taking the kvm-specific memory registration functions from all over the code, so we can make the merging with qemu easier. Note that I'm putting kvm_cpu_register_phys_memory() _inside_ cpu_register_phys_memory(). To do that, we need to be resilient against the same region being registered multiple times, and should be able to interpret the flags embedded in phys_offset in a meaninful way. Although arguably with some bugs yet unknown, this series does exactly that. For that to work, we have to be sure that we'll never reach a situation in which we register a piece of memory, and later on, register another region that contains it. Current code does that, so we're fine. The oposite situation, namely, registering a large piece of memory and then re-registering pieces of it, is perfectly valid. In the to-be-merged version, if it ever exists, I intend to comment all those issues very well, to get an as predictable interface as possible. There's another option of doing this, as anthony pointed out in earlier private comments to me, which is scanning the already registered regions right before starting execution, and building our maps. While this is valid, we can't run away from doing what I'm doing, because some areas are manipulated _after_ the machine has started. For example, the pci region, for the hotplug case. Note that this is not tested in anything but x86. Comments welcome. -- 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
