From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [RFC PATCH 0/9] ACPI memory hotplug Date: Tue, 24 Apr 2012 11:34:32 +0300 Message-ID: <20120424083432.GN15413@redhat.com> References: <1334844527-18869-1-git-send-email-vasilis.liaskovitis@profitbricks.com> <20120422135618.GA15413@redhat.com> <4F941073.8090702@redhat.com> <20120422140945.GC15413@redhat.com> <4F941207.6050508@redhat.com> <20120422142059.GD15413@redhat.com> <20120423123115.GB18286@dhcp-192-168-178-175.profitbricks.localdomain> <20120424075224.GK15413@redhat.com> <20120424082450.GC18286@dhcp-192-168-178-175.profitbricks.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: seabios@seabios.org, Avi Kivity , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Vasilis Liaskovitis Return-path: Content-Disposition: inline In-Reply-To: <20120424082450.GC18286@dhcp-192-168-178-175.profitbricks.localdomain> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On Tue, Apr 24, 2012 at 10:24:51AM +0200, Vasilis Liaskovitis wrote: > Hi, > On Tue, Apr 24, 2012 at 10:52:24AM +0300, Gleb Natapov wrote: > > On Mon, Apr 23, 2012 at 02:31:15PM +0200, Vasilis Liaskovitis wrote: > > > The 440fx spec mentions: "The address range from the top of main DRAM to 4 > > > Gbytes (top of physical memory space supported by the 440FX PCIset) is normally > > > mapped to PCI. The PMC forwards all accesses within this address range to PCI." > > > > > > What we probably want is that the initial memory map creation takes into account > > > all dimms specified (both populated/unpopulated) > > Yes. > > > > > So "-m 1G, -device dimm,size=1G,populated=true -device dimm,size=1G,populated=false" > > > would create a system map with top of memory and start of PCI-hole at 2G. > > > > > What -m 1G means on this command line? Isn't it redundant? > yes, this was redundant with the original concept. > > > May be we should make -m create non unplaggable, populated slot starting > > at address 0. Ten you config above will specify 3G memory with 2G > > populated (first of which is not removable) and 1G unpopulated. PCI hole > > starts above 3G. > > I agree -m should mean one big unpluggable slot. > > So in the new proposal,"-device dimm populated=true" means a hot-removable dimm > that has already been hotplugged. > Yes. > A question here is when exactly should the initial hot-add event for this dimm > be played? If the relevant OSPM has not yet been initialized (e.g. acpi_memhotplug > module in a linux guest needs to be loaded), the guest may not see the event. > This is a general issue of course, but with initially populated hot-removable > dimms it may be a bigger issue. Can ospm acpi initialization be detected? > > Or maybe you are suggesting "populated=true" is part of initial memory (i.e. not > hot-added, but still hot-removable). Though in that case guestOS may use it for > bootmem allocations, making hot-remove more likely to fail at the memory > offlining stage. > If memory slot is populated even before OSPM is started BIOS will detect that by reading mem_sts and will create e820 map appropriately. OSPM will detect it by evaluating _STA during boot. This is not unique for memory hot-plug. Any hotpluggable device have the same issue. -- Gleb.