From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36017) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TlK90-0004R5-DN for qemu-devel@nongnu.org; Wed, 19 Dec 2012 08:57:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TlK8z-0001KI-AP for qemu-devel@nongnu.org; Wed, 19 Dec 2012 08:57:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:2681) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TlK8z-0001KD-2X for qemu-devel@nongnu.org; Wed, 19 Dec 2012 08:57:09 -0500 Message-ID: <50D1C7A5.10801@redhat.com> Date: Wed, 19 Dec 2012 14:56:53 +0100 From: Gerd Hoffmann MIME-Version: 1.0 References: <1355834518-17989-1-git-send-email-vasilis.liaskovitis@profitbricks.com> <50D16C68.5020800@redhat.com> <20121219113553.GD4682@dhcp-192-168-178-175.profitbricks.localdomain> In-Reply-To: <20121219113553.GD4682@dhcp-192-168-178-175.profitbricks.localdomain> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vasilis Liaskovitis Cc: pingfank@linux.vnet.ibm.com, gleb@redhat.com, stefanha@gmail.com, jbaron@redhat.com, seabios@seabios.org, qemu-devel@nongnu.org, blauwirbel@gmail.com, kevin@koconnor.net, anthony@codemonkey.ws Hi, > correct, only the number of channels and ranks(dimms) per channel has been > emulated so far (2 channels of 4 dimms each). So it is still paravirtual memory > hotplug, not native. Native support still needs to be worked on. Ok. >> I think the paravirtual memory hotplug controller should be a PCI device >> (which we then can add as function to the chipset). Having some fixed >> magic addresses is bad. > > ok, so in your opinion a pci-based hotplug controller sounds better than adding > acpi ports to piix4 or ich9? > > Magic acpi_ich9 ports can be avoided if q35 native support is implemented. Yes. We should go that route for q35. > For > i440fx/piix4 it was discussed and more or less decided we would only support > a paravirtual way of memory hotplug. Sure, there is no other way to do it. It is probably a good idea to model piix4 paravirtual to work simliar to q35 native. > In the description. I meant "paravirtual memory bus" to describe a memory bus > with unlimited number of dimm devices. But the "hotplug control" has always > been acpi-based so far and not a pci device. It still can (and should) be acpi-based. It is just that: (a) Instead of using get_system_io() as parent memory region you use create a pci device and place the memory region in one of the PCI bars. (b) Instead of using OperationRegion($name, SystemIO, $magicaddress) you use OperationRegion($name, PciBarTarget, ...) to access the registers. cheers, Gerd