From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC 0/9] Memory registration rework Date: Wed, 13 Aug 2008 14:43:20 +0300 Message-ID: <48A2C8D8.90001@qumranet.com> References: <1218588489-17182-1-git-send-email-gcosta@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, aliguori@us.ibm.com To: Glauber Costa Return-path: Received: from il.qumranet.com ([212.179.150.194]:33169 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752337AbYHMLnY (ORCPT ); Wed, 13 Aug 2008 07:43:24 -0400 In-Reply-To: <1218588489-17182-1-git-send-email-gcosta@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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