qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Alexander Graf <agraf@suse.de>
Cc: qemu-ppc <qemu-ppc@nongnu.org>, QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH v2] spapr: add ibm, (get|set)-system-parameter
Date: Tue, 19 Nov 2013 12:23:43 +1100	[thread overview]
Message-ID: <528ABD9F.8000604@ozlabs.ru> (raw)
In-Reply-To: <0CFB910D-323F-4E29-AE6D-6721BBFF1E0D@suse.de>

On 11/19/2013 07:58 AM, Alexander Graf wrote:
> 
> On 17.11.2013, at 22:09, Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> 
>> This adds very basic handlers for ibm,get-system-parameter and
>> ibm,set-system-parameter RTAS calls.
>>
>> The only parameter handled at the moment is
>> "platform-processor-diagnostics-run-mode" which is always disabled and
>> does not support changing. This is expected to make
>> "ppc64_cpu --run-mode=1" happy.
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> ---
>> Changes:
>> v2:
>> * addressed comments from Alex Graf
>> ---
>> hw/ppc/spapr_rtas.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 48 insertions(+)
>>
>> diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
>> index eb542f2..8053a67 100644
>> --- a/hw/ppc/spapr_rtas.c
>> +++ b/hw/ppc/spapr_rtas.c
>> @@ -224,6 +224,50 @@ static void rtas_stop_self(PowerPCCPU *cpu, sPAPREnvironment *spapr,
>>     env->msr = 0;
>> }
>>
>> +#define DIAGNOSTICS_RUN_MODE        42
>> +
>> +static void rtas_ibm_get_system_parameter(PowerPCCPU *cpu,
>> +                                          sPAPREnvironment *spapr,
>> +                                          uint32_t token, uint32_t nargs,
>> +                                          target_ulong args,
>> +                                          uint32_t nret, target_ulong rets)
>> +{
>> +    target_ulong papameter = rtas_ld(args, 0);
>> +    target_ulong buffer = rtas_ld(args, 1);
>> +    target_ulong length = rtas_ld(args, 2);
>> +    target_ulong ret = -3; /* System parameter is not supported */
> 
> Is this an RTAS function defined return value or a global RTAS return value?


Sorry for my ignorance, I do not understand the question. So far every RTAS
call I looked at defined all return codes right in the description of the call.

Like this (sorry, cut-n-paste from PDF killed formatting but the point is
still valid):

 7.3.16.2 ibm,set-system-parameter
Table 96. ibm,set-system-parameter Argument Call Buffer
Parameter Type
Name
Token
Values
Token for ibm,set-system-parameter
Number Inputs
In
2
Number Outputs 1
Parameter
Token number of the target system parameter
buffer
Out
Real address of data buffer
Status 0: Success
      -1: Hardware Error
     -2: Busy, Try again later
    -3: System parameter not supported
   -9002: Setting not allowed/authorized
  -9999: Parameter Error
 990x:Extended delay where x is a number 0-5 (see text below)



>> +
>> +    switch (papameter) {
>> +    case DIAGNOSTICS_RUN_MODE:
>> +        if (length == 1) {
>> +            rtas_st(buffer, 0, 0);
>> +            ret = 0; /* Success */
> 
> I assume this one is RTAS global?
> 
>> +        }
>> +        break;
>> +    }
>> +
>> +    rtas_st(rets, 0, ret);
>> +}
>> +
>> +static void rtas_ibm_set_system_parameter(PowerPCCPU *cpu,
>> +                                          sPAPREnvironment *spapr,
>> +                                          uint32_t token, uint32_t nargs,
>> +                                          target_ulong args,
>> +                                          uint32_t nret, target_ulong rets)
>> +{
>> +    target_ulong papameter = rtas_ld(args, 0);
>> +    /* target_ulong buffer = rtas_ld(args, 1); */
> 
> Not addressed. Just remove this line until it gets used.

What is bad in having such a comment? I thought by having one return per
function we help other people from the future to add functionality easier
and such comment would help them too.


>> +    target_ulong ret = -3; /* System parameter is not supported */
>> +
>> +    switch (papameter) {
>> +    case DIAGNOSTICS_RUN_MODE:
>> +        ret = -9002; /* Setting not allowed/authorized */
> 
> -9002 seems to always mean "Not Authorized".
>
> In fact, reading through the PAPR spec it seems as if we can easily give
> return values reasonable names:
>
>   #define RTAS_OUT_SUCCESS 0
>   #define RTAS_OUT_ERROR -1
>   #define RTAS_OUT_BUSY -2
>   #define RTAS_OUT_NOT_SUPPORTED -3
>   #define RTAS_OUT_NOMEM -5
>   #define RTAS_OUT_NOT_AUTHORIZED -9002
>   #define RTAS_OUT_PARAM_ERROR -9999


These are RTAS local, noone else really cares about them. The kernel uses
numbers too (arch/powerpc/kernel/rtas.c). Why should I replace easy
understandable (look at spec -> look at gdb -> everything is clear) numbers
with definitions?


> We can't always have a 1:1 map between name and number, but at least
> name -> number should always be unique:

>   (ibm,configure-connector)
>   #define RTAS_OUT_DR_CONN_UNUSABLE -9003
>   #define RTAS_OUT_DR_CONN_NOT_SUPPORTED -9002
>   #define RTAS_OUT_DR_SYSTEM_NOT_SUPPORTED -9001
> 
> Do you see cases where this wouldn't work out? That way we don't have to
> have explicit comments in the code explaining what a return value really
> means, making the code more easy to read.


I need to skim the whole PAPR to make sure that this is the case and then
skim the guest kernel to make sure it is not broken somewhere. And I do not
see any profit from this job and it will definitely make my life harder as
I really (really) want to see exact numbers in the code when I debug binary
interface.


However you can always ignore my comments and say "do what I say" and I'll
do, no big deal. Thanks.


-- 
Alexey

  reply	other threads:[~2013-11-19  1:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-18  3:09 [Qemu-devel] [PATCH v2] spapr: add ibm,(get|set)-system-parameter Alexey Kardashevskiy
2013-11-18 20:58 ` [Qemu-devel] [PATCH v2] spapr: add ibm, (get|set)-system-parameter Alexander Graf
2013-11-19  1:23   ` Alexey Kardashevskiy [this message]
2013-11-19 10:29     ` 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=528ABD9F.8000604@ozlabs.ru \
    --to=aik@ozlabs.ru \
    --cc=agraf@suse.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).