From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56759) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xqbtb-0005JJ-Qt for qemu-devel@nongnu.org; Tue, 18 Nov 2014 01:04:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XqbtV-0003ZN-Ee for qemu-devel@nongnu.org; Tue, 18 Nov 2014 01:04:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38247) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqbtV-0003Z9-7y for qemu-devel@nongnu.org; Tue, 18 Nov 2014 01:04:05 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAI643cI017409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 18 Nov 2014 01:04:03 -0500 Message-ID: <546AE14E.7060606@redhat.com> Date: Tue, 18 Nov 2014 07:03:58 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1416254843-16859-1-git-send-email-mst@redhat.com> <1416254843-16859-3-git-send-email-mst@redhat.com> In-Reply-To: <1416254843-16859-3-git-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" , qemu-devel@nongnu.org Cc: dgilbert@redhat.com, Juan Quintela On 17/11/2014 21:08, Michael S. Tsirkin wrote: > Add API to manage on-device RAM. > This looks just like regular RAM from migration POV, > but has two special properties internally: > > - block is sized on migration, making it easier to extend > without breaking migration compatibility or wasting > virtual memory > - callers must specify an upper bound on size Why should on-device RAM have this property, or why should this property be interesting for on-device RAM (as opposed to generic "we are using MemoryRegions internally and we want them resized")? I admit the patches look clean, but I would prefer to have some changes to the API and I dislike introducing a worse API just because we are so close to release. For example, the resized callback should probably receive a MemoryRegion, not a host/length pair, or even better there could be a NotifierList per RAMBlock. Also, I am afraid that this design could make it easier to introduce backwards-incompatible changes. I very much prefer to have user-controlled ACPI information (coming from the command-line) byte-for-byte identical for a given machine type. Patches for that have been on the list for almost two months, and it's not nice. Paolo