Glauber Costa wrote:
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.
Looks good. The current duplication of memory registration is very
annoying.
--
error compiling committee.c: too many arguments to function
--
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
