From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:56782 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932942AbdCWNSN (ORCPT ); Thu, 23 Mar 2017 09:18:13 -0400 Date: Thu, 23 Mar 2017 14:12:52 +0100 From: Stanislaw Gruszka To: Ankur Arora Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, stable@vger.kernel.org Subject: Re: [PATCH 2/2 v2] xen/acpi: upload PM state from init-domain to Xen Message-ID: <20170323131252.GA6008@redhat.com> References: <1490136218-3857-1-git-send-email-ankur.a.arora@oracle.com> <1490136218-3857-3-git-send-email-ankur.a.arora@oracle.com> <20170322090541.GA2860@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: stable-owner@vger.kernel.org List-ID: On Wed, Mar 22, 2017 at 10:56:02AM -0700, Ankur Arora wrote: > >It is ok to do upload_pm_data() with delay i.e. after some other > >resume actions are done and possibly xen-acpi-processor is in > >running state ? > The state uploaded is ACPI P and C state from struct acpi_processor > which AFAICS is stable once inited so a delay would not lead to > invalid state. > The only concern would be the ACPI pCPU hotplug logic in > acpi_processor_add() which could add a new entry in > per_cpu(processors) but that also looks okay because either we > get a NULL or we get a pointer to an inited structure. > > As for the hypervisor -- that falls back to more limited state after > resume (because some of this state is thrown away at suspend) and so > uses that until it gets the uploaded PM state from the initial-domain. Patch looks good to me then. Reviewed-by: Stanislaw Gruszka