From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NWsti-000728-N1 for qemu-devel@nongnu.org; Mon, 18 Jan 2010 09:48:06 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NWstd-0006zm-Vg for qemu-devel@nongnu.org; Mon, 18 Jan 2010 09:48:06 -0500 Received: from [199.232.76.173] (port=47099 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NWstd-0006zV-Nm for qemu-devel@nongnu.org; Mon, 18 Jan 2010 09:48:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:12242) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NWstd-0000UQ-87 for qemu-devel@nongnu.org; Mon, 18 Jan 2010 09:48:01 -0500 Date: Mon, 18 Jan 2010 16:44:56 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] [PATCHv2 1/3] qemu: memory notifiers Message-ID: <20100118144456.GD8317@redhat.com> References: <20100104194904.GB21299@redhat.com> <4B545C03.40807@redhat.com> <20100118135234.GC8317@redhat.com> <4B54691B.7090601@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B54691B.7090601@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: gleb@redhat.com, qemu-devel@nongnu.org On Mon, Jan 18, 2010 at 03:58:51PM +0200, Avi Kivity wrote: > On 01/18/2010 03:52 PM, Michael S. Tsirkin wrote: >> On Mon, Jan 18, 2010 at 03:02:59PM +0200, Avi Kivity wrote: >> >>> On 01/04/2010 09:49 PM, Michael S. Tsirkin wrote: >>> >>>> This adds notifiers for phys memory changes: a set of callbacks that >>>> vhost can register and update kernel accordingly. Down the road, kvm >>>> code can be switched to use these as well, instead of calling kvm code >>>> directly from exec.c as is done now. >>>> >>>> >>>> + >>>> +static void phys_page_for_each_in_l1_map(PhysPageDesc **phys_map, >>>> + CPUPhysMemoryClient *client) >>>> +{ >>>> + PhysPageDesc *pd; >>>> + int l1, l2; >>>> + >>>> + for (l1 = 0; l1< L1_SIZE; ++l1) { >>>> + pd = phys_map[l1]; >>>> + if (!pd) { >>>> + continue; >>>> + } >>>> + for (l2 = 0; l2< L2_SIZE; ++l2) { >>>> + if (pd[l2].phys_offset == IO_MEM_UNASSIGNED) { >>>> + continue; >>>> + } >>>> + client->set_memory(client, pd[l2].region_offset, >>>> + TARGET_PAGE_SIZE, pd[l2].phys_offset); >>>> + } >>>> + } >>>> +} >>>> + >>>> +static void phys_page_for_each(CPUPhysMemoryClient *client) >>>> +{ >>>> +#if TARGET_PHYS_ADDR_SPACE_BITS> 32 >>>> + >>>> +#if TARGET_PHYS_ADDR_SPACE_BITS> (32 + L1_BITS) >>>> +#error unsupported TARGET_PHYS_ADDR_SPACE_BITS >>>> +#endif >>>> + void **phys_map = (void **)l1_phys_map; >>>> + int l1; >>>> + if (!l1_phys_map) { >>>> + return; >>>> + } >>>> + for (l1 = 0; l1< L1_SIZE; ++l1) { >>>> + if (phys_map[l1]) { >>>> + phys_page_for_each_in_l1_map(phys_map[l1], client); >>>> + } >>>> + } >>>> +#else >>>> + if (!l1_phys_map) { >>>> + return; >>>> + } >>>> + phys_page_for_each_in_l1_map(l1_phys_map, client); >>>> +#endif >>>> +} >>>> >>>> >>> This looks pretty frightening. What is it needed for? >>> >> The point is that clients can be registered at any point. >> >> A client that registered when memory is present needs to >> be notified about it. >> > > It looks very expensive. Shouldn't be hard to optimize ... > Maybe we mandate clients be registered at init-time? This might be tricky - vhost currently only registers when the first device is hot-added. > Long term we need to move to a range based memory description. > > -- > error compiling committee.c: too many arguments to function