DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9EF637F415
Date: Thu, 23 Mar 2017 14:12:52 +0100
From: Stanislaw Gruszka <sgruszka@redhat.com>
To: Ankur Arora <ankur.a.arora@oracle.com>
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>
 <a1f0404e-899e-8d56-ef65-858dacecb62d@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a1f0404e-899e-8d56-ef65-858dacecb62d@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 903
Lines: 19

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 <sgruszka@redhat.com>