From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoffer Dall Subject: Re: [PATCH 19/19] Documentation: ACPI for ARM64 Date: Wed, 30 Jul 2014 09:14:39 +0200 Message-ID: References: <1406206825-15590-1-git-send-email-hanjun.guo@linaro.org> <20140729112824.GM2576@leverpostej> <351673188.FxXsM7MvdA@wuerfel> <20140729130823.GP2576@leverpostej> <53D894F0.1060102@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53D894F0.1060102@linaro.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Hanjun Guo Cc: Mark Rutland , Mark Brown , Catalin Marinas , Will Deacon , Lv Zheng , "rob.herring@linaro.org" , Lorenzo Pieralisi , Daniel Lezcano , Robert Moore , "linux-acpi@vger.kernel.org" , "grant.likely@linaro.org" , Charles Garcia-Tobin , Robert Richter , Jason Cooper , Arnd Bergmann , Marc Zyngier , Liviu Dudau , Bjorn Helgaas , "linux-arm-kernel@lists.infradead.org" , "graeme.gregory@linaro.org" , Randy List-Id: linux-acpi@vger.kernel.org On 30 July 2014 08:47, Hanjun Guo wrote: > On 2014-7-29 21:31, Christoffer Dall wrote: >> On 29 July 2014 15:08, Mark Rutland wrote: >>> On Tue, Jul 29, 2014 at 01:52:40PM +0100, Arnd Bergmann wrote: >>>> On Tuesday 29 July 2014 14:37:38 Christoffer Dall wrote: >>>>> >>>>> For reference, Red Hat's current arguing point for ACPI in VMs is >>>>> hotplug of things like CPUs and memory for very large VMs, but I >>>>> haven't thought too carefully about this just yet, as I don't have a >>>>> 100+ core ARM 64-bit hardware lying around... >>>> >>>> I thought you could run guests with more virtual CPUs that you have >>>> physical CPUs on the host. >>>> >>>> Regarding CPU and memory hotplug, don't we already have PSCI and >>>> xen-balloon/virtio-balloon for that? >>> >>> PSCI (0.1) was there for guests from the start, and ACPI doesn't do >>> anything different w.r.t. PSCI other than requiring PSCI 0.2 (which can >>> be used by guests supporting only PSCI 0.1). So there's no magic for >>> CPU hotplug provided by ACPI. >> >> With PSCI you can only provide your VM a bunch of CPUs and say that >> they're all turned off, and then turn some of them on later. > > Yes, agreed. > >> I honestly don't know if you can do proper CPU hotplug with ACPI, but >> the RH guys seem to argue that you can. Again, I didn't think too >> carefully about this. > > Yes, we can do proper CPU hotplug with ACPI based physical hotplug (named > dynamic device configuration in ACPI spec), you can refer to section 6.3 > "Device Insertion, Removal, and Status Objects" in ACPI 5.1. > > There are mechanisms for handling dynamic insertion and removal of devices > and for determining device and notification processing status. When removing > a processor, > > a) we will call PSCI or similar interface to offline a CPU from OS, then > OS will not use it any more; > > b) call ACPI API to trim the resources that allocated during device > enumeration; > > c) Call ACPI method _EJ0 and then will notify firmware or hypervisor device > will be removed, jump to firmware or hypervisor to remove the device > from that level; When you say notify hypervisor, would we really need a hypervisor-specific interface if you're running UEFI as your firmware? Can you not just call whatever UEFI service to remove a CPU and let that UEFI implementation deal with the hypervisor/hardware interface? -Christoffer From mboxrd@z Thu Jan 1 00:00:00 1970 From: christoffer.dall@linaro.org (Christoffer Dall) Date: Wed, 30 Jul 2014 09:14:39 +0200 Subject: [PATCH 19/19] Documentation: ACPI for ARM64 In-Reply-To: <53D894F0.1060102@linaro.org> References: <1406206825-15590-1-git-send-email-hanjun.guo@linaro.org> <20140729112824.GM2576@leverpostej> <351673188.FxXsM7MvdA@wuerfel> <20140729130823.GP2576@leverpostej> <53D894F0.1060102@linaro.org> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 30 July 2014 08:47, Hanjun Guo wrote: > On 2014-7-29 21:31, Christoffer Dall wrote: >> On 29 July 2014 15:08, Mark Rutland wrote: >>> On Tue, Jul 29, 2014 at 01:52:40PM +0100, Arnd Bergmann wrote: >>>> On Tuesday 29 July 2014 14:37:38 Christoffer Dall wrote: >>>>> >>>>> For reference, Red Hat's current arguing point for ACPI in VMs is >>>>> hotplug of things like CPUs and memory for very large VMs, but I >>>>> haven't thought too carefully about this just yet, as I don't have a >>>>> 100+ core ARM 64-bit hardware lying around... >>>> >>>> I thought you could run guests with more virtual CPUs that you have >>>> physical CPUs on the host. >>>> >>>> Regarding CPU and memory hotplug, don't we already have PSCI and >>>> xen-balloon/virtio-balloon for that? >>> >>> PSCI (0.1) was there for guests from the start, and ACPI doesn't do >>> anything different w.r.t. PSCI other than requiring PSCI 0.2 (which can >>> be used by guests supporting only PSCI 0.1). So there's no magic for >>> CPU hotplug provided by ACPI. >> >> With PSCI you can only provide your VM a bunch of CPUs and say that >> they're all turned off, and then turn some of them on later. > > Yes, agreed. > >> I honestly don't know if you can do proper CPU hotplug with ACPI, but >> the RH guys seem to argue that you can. Again, I didn't think too >> carefully about this. > > Yes, we can do proper CPU hotplug with ACPI based physical hotplug (named > dynamic device configuration in ACPI spec), you can refer to section 6.3 > "Device Insertion, Removal, and Status Objects" in ACPI 5.1. > > There are mechanisms for handling dynamic insertion and removal of devices > and for determining device and notification processing status. When removing > a processor, > > a) we will call PSCI or similar interface to offline a CPU from OS, then > OS will not use it any more; > > b) call ACPI API to trim the resources that allocated during device > enumeration; > > c) Call ACPI method _EJ0 and then will notify firmware or hypervisor device > will be removed, jump to firmware or hypervisor to remove the device > from that level; When you say notify hypervisor, would we really need a hypervisor-specific interface if you're running UEFI as your firmware? Can you not just call whatever UEFI service to remove a CPU and let that UEFI implementation deal with the hypervisor/hardware interface? -Christoffer