All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Fontenot <nfont@linux.vnet.ibm.com>
To: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>,
	Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org, Cyril Bur <cyrilbur@gmail.com>
Subject: Re: [PATCH 1/3] powerpc/pseries: Simplify check for suspendability during suspend/migration
Date: Wed, 04 Mar 2015 09:58:48 -0600	[thread overview]
Message-ID: <54F72BB8.2080001@linux.vnet.ibm.com> (raw)
In-Reply-To: <54F616A3.9030807@linux.vnet.ibm.com>

On 03/03/2015 02:16 PM, Tyrel Datwyler wrote:
> On 03/02/2015 10:15 PM, Michael Ellerman wrote:
>> On Mon, 2015-03-02 at 13:30 -0800, Tyrel Datwyler wrote:
>>> On 03/01/2015 08:19 PM, Cyril Bur wrote:
>>>> On Fri, 2015-02-27 at 18:24 -0800, Tyrel Datwyler wrote:
>>>>> During suspend/migration operation we must wait for the VASI state reported
>>>>> by the hypervisor to become Suspending prior to making the ibm,suspend-me
>>>>> RTAS call. Calling routines to rtas_ibm_supend_me() pass a vasi_state variable
>>>>> that exposes the VASI state to the caller. This is unnecessary as the caller
>>>>> only really cares about the following three conditions; if there is an error
>>>>> we should bailout, success indicating we have suspended and woken back up so
>>>>> proceed to device tree updated, or we are not suspendable yet so try calling
>>>>> rtas_ibm_suspend_me again shortly.
>>>>>
>>>>> This patch removes the extraneous vasi_state variable and simply uses the
>>>>> return code to communicate how to proceed. We either succeed, fail, or get
>>>>> -EAGAIN in which case we sleep for a second before trying to call
>>>>> rtas_ibm_suspend_me again.
>>>>>
>>>>>  		u64 handle = ((u64)be32_to_cpu(args.args[0]) << 32)
>>>>>  		              | be32_to_cpu(args.args[1]);
>>>>> -		rc = rtas_ibm_suspend_me(handle, &vasi_rc);
>>>>> -		args.rets[0] = cpu_to_be32(vasi_rc);
>>>>> -		if (rc)
>>>>> +		rc = rtas_ibm_suspend_me(handle);
>>>>> +		if (rc == -EAGAIN)
>>>>> +			args.rets[0] = cpu_to_be32(RTAS_NOT_SUSPENDABLE);
>>>>
>>>> (continuing on...) so perhaps here have
>>>> 	rc = 0;
>>>> else if (rc == -EIO)
>>>> 	args.rets[0] = cpu_to_be32(-1);
>>>> 	rc = 0;
>>>> Which should keep the original behaviour, the last thing we want to do
>>>> is break BE.
>>>
>>> The biggest problem here is we are making what basically equates to a
>>> fake rtas call from drmgr which we intercept in ppc_rtas(). From there
>>> we make this special call to rtas_ibm_suspend_me() to check VASI state
>>> and do a bunch of other specialized work that needs to be setup prior to
>>> making the actual ibm,suspend-me rtas call. Since, we are cheating PAPR
>>> here I guess we can really handle it however we want. I chose to simply
>>> fail the rtas call in the case where rtas_ibm_suspend_me() fails with
>>> something other than -EAGAIN. In user space librtas will log errno for
>>> the failure and return RTAS_IO_ASSERT to drmgr which in turn will log
>>> that error and fail.
>>
>> We don't want to change the return values of the syscall unless we absolutely
>> have to. And I don't think that's the case here.
> 
> I'd like to argue that the one case I changed makes sense, but its just
> as easy to keep the original behavior.
> 
>>
>> Sure we think drmgr is the only thing that uses this crap, but we don't know
>> for sure.
> 
> I can't imagine how anybody else could possibly use this hack without a
> streamid from the hmc/hypervisor, but I've been wrong in the past more
> times than I can count. :)

Correct, this will fail if called with a random streamid. The streamid has
to match what is handed to us from the HMC when a migration request is
initiated.

-Nathan
 
> 
> -Tyrel
> 
>>
>> cheers
>>
>>
> 

  reply	other threads:[~2015-03-04 15:58 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-28  2:24 [PATCH 0/3] powerpc/pseries: Fixes and cleanup of suspend/migration code Tyrel Datwyler
2015-02-28  2:24 ` [PATCH 1/3] powerpc/pseries: Simplify check for suspendability during suspend/migration Tyrel Datwyler
2015-03-02  4:19   ` Cyril Bur
2015-03-02 21:30     ` Tyrel Datwyler
2015-03-03  6:15       ` Michael Ellerman
2015-03-03 20:16         ` Tyrel Datwyler
2015-03-04 15:58           ` Nathan Fontenot [this message]
2015-02-28  2:24 ` [PATCH 2/3] powerpc/pseries: Little endian fixes for post mobility device tree update Tyrel Datwyler
2015-03-02  5:20   ` Cyril Bur
2015-03-02 21:49     ` Tyrel Datwyler
2015-03-03 23:15       ` Tyrel Datwyler
2015-03-04  1:20         ` Cyril Bur
2015-03-04  1:41           ` Tyrel Datwyler
2015-02-28  2:24 ` [PATCH 3/3] powerpc/pseries: Expose post-migration in kernel device tree update to drmgr Tyrel Datwyler
2015-03-03  6:24   ` Michael Ellerman
2015-03-03 21:18     ` Tyrel Datwyler
2015-03-03  6:10 ` [PATCH 0/3] powerpc/pseries: Fixes and cleanup of suspend/migration code Michael Ellerman
2015-03-03 20:37   ` Tyrel Datwyler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54F72BB8.2080001@linux.vnet.ibm.com \
    --to=nfont@linux.vnet.ibm.com \
    --cc=cyrilbur@gmail.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=tyreld@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.