From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39533) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TQFfg-0003RI-AC for qemu-devel@nongnu.org; Mon, 22 Oct 2012 06:55:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TQFfe-0007Lu-Uy for qemu-devel@nongnu.org; Mon, 22 Oct 2012 06:55:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58112) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TQFfe-0007Lq-II for qemu-devel@nongnu.org; Mon, 22 Oct 2012 06:55:46 -0400 Message-ID: <50852622.8000708@redhat.com> Date: Mon, 22 Oct 2012 12:55:30 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1348226255-4226-1-git-send-email-vasilis.liaskovitis@profitbricks.com> <1348226255-4226-7-git-send-email-vasilis.liaskovitis@profitbricks.com> <20120924104242.GA4457@dhcp-192-168-178-175.profitbricks.localdomain> <20121009170429.GF16311@dhcp-192-168-178-175.profitbricks.localdomain> <20121017091923.GA27484@dhcp-192-168-178-175.profitbricks.localdomain> <507E8287.3040709@redhat.com> <20121018092737.GA26373@dhcp-192-168-178-175.profitbricks.localdomain> <507FF6FE.5070301@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v3 06/19] Implement "-dimm" command line option List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: kvm@vger.kernel.org, seabios@seabios.org, qemu-devel@nongnu.org, gleb@redhat.com, Vasilis Liaskovitis , kevin@koconnor.net, kraxel@redhat.com, anthony@codemonkey.ws, imammedo@redhat.com On 10/19/2012 07:48 PM, Blue Swirl wrote: >>> >>> DIMMs would be allowed to be hotplugged in the generic mem-controller scheme only >>> (unless it makes sense to allow hotplug in the remaining pmc DRBs and >>> start using the generic scheme once we run out of emulated DRBs) >>> >> >> 440fx seems a lost cause, so we can go wild and just implement pv dimms. > > Maybe. But what would be a PV DIMM? Do we need any DIMM-like > granularity at all, instead the guest could be told to use a list of > RAM regions with arbitrary start and end addresses? Guests are likely to support something that has the same constraints as real hardware. If we allow non-power-of-two DIMMs, we might find that guests don't support them well. > Isn't ballooning > also related? It is related in that it is also a memory hotplug technology. But ballooning is subtractive and fine-grained where classic hotplug is additive and coarse grained. We can use both together, but I don't think any work is needed at the qemu level. > >> For q35 I'd like to stay within the spec. > > That may not last forever when machines have terabytes of memory. At least there's work for chipset implementers. Or we can do PV-DIMMs for q35 too. -- error compiling committee.c: too many arguments to function