All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
To: Alexander Graf <agraf@suse.de>, qemu-devel@nongnu.org
Cc: aik@au1.ibm.com, qemu-ppc@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2] ppc: spapr-rtas - implement os-term rtas call
Date: Tue, 17 Jun 2014 15:49:26 +0530	[thread overview]
Message-ID: <87vbrzale9.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <53A01220.90009@suse.de>

Alexander Graf <agraf@suse.de> writes:

> On 17.06.14 11:59, Nikunj A Dadhania wrote:
>> Alexander Graf <agraf@suse.de> writes:
>>> On 17.06.14 11:30, Nikunj A Dadhania wrote:
>>>> Alexander Graf <agraf@suse.de> writes:

>>>>>> +    spapr_rtas_register("ibm,os-term", rtas_ibm_os_term);
>>>>>> +    spapr_rtas_register("ibm,extended-os-term", rtas_ibm_ext_os_term);
>>>>> Why do we need the extended-os-term if we don't do anything with it?
>>>> Linux kernel checks for both of them because of legacy:
>>>>
>>>> arch/powerpc/kernel/rtas.c:
>>>>
>>>> void rtas_os_term(char *str)
>>>> {
>>>> [...]
>>>>           /*
>>>>            * Firmware with the ibm,extended-os-term property is guaranteed
>>>>            * to always return from an ibm,os-term call. Earlier versions without
>>>>            * this property may terminate the partition which we want to avoid
>>>>            * since it interferes with panic_timeout.
>>> But we do not return from the RTAS call, so we don't adhere to the
>>> extended semantics?
>> But you would return without calling os-term call if
>> ibm,extended-os-term isnt registered. For that reason I h       ave defined a
>> stub.
>
> I appreciate the hacker mentality, but Linux explicitly checks on 
> ibm,extended-os-term to ensure that the hypervisor does not stop the VM 
> when it calls ibm,os-term. However, the implementation above does stop 
> the VM when the guest calls ibm,os-term.

Seems to be added to do just that:

commit e9bbc8cde0e3c33b42ddbe1b02108cb5c97275eb
Author: Anton Blanchard <anton@samba.org>
Date:   Thu Feb 18 12:11:51 2010 +0000

    powerpc/pseries: Call ibm,os-term if the ibm,extended-os-term is present
    
    We have had issues in the past with ibm,os-term initiating shutdown of a
    partition. This is confusing to the user, especially if panic_timeout is
    non zero.
    
    The temporary fix was to avoid calling ibm,os-term if a panic_timeout was set
    and since we set it on every boot we basically never call ibm,os-term.
    
    An extended version of ibm,os-term has since been implemented which gives us
    the behaviour we want:
    
      "When the platform supports extended ibm,os-term behavior, the return to the
      RTAS will always occur unless there is a kernel assisted dump active as
      initiated by an ibm,configure-kernel-dump call."
    
    This patch checks for the ibm,extended-os-term property and calls ibm,os-term
    if it exists.
    
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

> Why was that check put into place?


Regards
Nikunj

  reply	other threads:[~2014-06-17 10:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-12 12:09 [Qemu-devel] [PATCH v2] ppc: spapr-rtas - implement os-term rtas call Nikunj A Dadhania
2014-06-17  9:13 ` Alexander Graf
2014-06-17  9:30   ` Nikunj A Dadhania
2014-06-17  9:53     ` Alexander Graf
2014-06-17  9:59       ` Nikunj A Dadhania
2014-06-17 10:02         ` Alexander Graf
2014-06-17 10:19           ` Nikunj A Dadhania [this message]
2014-06-25  4:36             ` Nikunj A Dadhania
2014-06-25 11:03               ` Alexander Graf
2014-06-25 11:27                 ` Nikunj A Dadhania
2014-06-25 11:32                   ` Alexander Graf
2014-06-26  7:55                     ` Nikunj A Dadhania
2014-06-26  8:04                       ` Alexander Graf
2014-06-26  9:05                         ` Nikunj A Dadhania
2014-06-26  9:22                           ` Alexander Graf

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=87vbrzale9.fsf@linux.vnet.ibm.com \
    --to=nikunj@linux.vnet.ibm.com \
    --cc=agraf@suse.de \
    --cc=aik@au1.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /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.