Re: [RFC 0/9] Memory registration rework

[Avi Kivity <avi@qumranet.com>]

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