[RFC 0/9] Memory registration rework

Glauber Costa
2008-08-13T00:53:30Z

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.