All of lore.kernel.org
 help / color / mirror / Atom feed
From: kajoljain <kjain@linux.ibm.com>
To: Nathan Lynch <nathanl@linux.ibm.com>
Cc: ravi.bangoria@linux.ibm.com, maddy@linux.vnet.ibm.com,
	anju@linux.vnet.ibm.com, peterz@infradead.org,
	gregkh@linuxfoundation.org, suka@us.ibm.com,
	alexander.shishkin@linux.intel.com, mingo@kernel.org,
	mpetlan@redhat.com, yao.jin@linux.intel.com, ak@linux.intel.com,
	mamatha4@linux.vnet.ibm.com, acme@kernel.org, jmario@redhat.com,
	namhyung@kernel.org, linuxppc-dev@lists.ozlabs.org,
	jolsa@kernel.org, kan.liang@linux.intel.com
Subject: Re: [PATCH v8 2/5] powerpc/hv-24x7: Add rtas call in hv-24x7 driver to get processor details
Date: Mon, 18 May 2020 11:02:25 +0530	[thread overview]
Message-ID: <9c392907-03b2-bd09-51df-41609e802d6c@linux.ibm.com> (raw)
In-Reply-To: <87blmu2nac.fsf@linux.ibm.com>



On 5/12/20 2:37 AM, Nathan Lynch wrote:
> Hi,
> 
> Kajol Jain <kjain@linux.ibm.com> writes:
>> diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
>> index 48e8f4b17b91..8cf242aad98f 100644
>> --- a/arch/powerpc/perf/hv-24x7.c
>> +++ b/arch/powerpc/perf/hv-24x7.c
>> @@ -20,6 +20,7 @@
>>  #include <asm/io.h>
>>  #include <linux/byteorder/generic.h>
>>  
>> +#include <asm/rtas.h>
>>  #include "hv-24x7.h"
>>  #include "hv-24x7-catalog.h"
>>  #include "hv-common.h"
>> @@ -57,6 +58,75 @@ static bool is_physical_domain(unsigned domain)
>>  	}
>>  }
>>  
>> +/*
>> + * The Processor Module Information system parameter allows transferring
>> + * of certain processor module information from the platform to the OS.
>> + * Refer PAPR+ document to get parameter token value as '43'.
>> + */
>> +
>> +#define PROCESSOR_MODULE_INFO   43
>> +#define PROCESSOR_MAX_LENGTH	(8 * 1024)
>> +
>> +DEFINE_SPINLOCK(rtas_local_data_buf_lock);
>> +EXPORT_SYMBOL(rtas_local_data_buf_lock);
> 
> This should be static and not exported, correct?
> 
>> +
>> +static u32 phys_sockets;	/* Physical sockets */
>> +static u32 phys_chipspersocket;	/* Physical chips per socket*/
>> +static u32 phys_coresperchip; /* Physical cores per chip */
>> +
>> +/*
>> + * Function read_sys_info_pseries() make a rtas_call which require
>> + * data buffer of size 8K. As standard 'rtas_data_buf' is of size
>> + * 4K, we are adding new local buffer 'rtas_local_data_buf'.
> 
> Sorry if this has been covered before but I don't understand why it
> would require a larger buffer; by my reading this call will return *ten
> bytes* of output. Also, current versions of PAPR+ limit the output
> length to 4002 bytes. I feel like I'm missing something.
> 

Hi Nathan,
	Thanks for reviewing the patch. Actually when I was testing this patch in
both power8 and power9 machine, I got some issue in power9 because of buffer size.
And I checked the buffer size used in util_linux which is 8192. So, I increase the
buffer size.I will again test it as I did couple of changes after that with 4002 size. 

> 
>> + */
>> +static __be16 rtas_local_data_buf[PROCESSOR_MAX_LENGTH] __cacheline_aligned;
>> +
>> +/*
>> + * read_sys_info_pseries()
>> + * Retrieve the number of sockets and chips per socket and cores per
>> + * chip details through the get-system-parameter rtas call.
>> + */
>> +void read_sys_info_pseries(void)
>> +{
>> +	int call_status, len, ntypes;
>> +
>> +	/*
>> +	 * Making system parameter: chips and sockets and cores per chip
>> +	 * default to 1.
>> +	 */
>> +	phys_sockets = 1;
>> +	phys_chipspersocket = 1;
>> +	phys_coresperchip = 1;
>> +	memset(rtas_local_data_buf, 0, PROCESSOR_MAX_LENGTH * sizeof(__be16));
> 
> Modifying global state outside of any critical section...? How do
> you prevent readers from seeing inconsistent results?

Yes right, Will update.

> 
> 
>> +	spin_lock(&rtas_local_data_buf_lock);
>> +
>> +	call_status = rtas_call(rtas_token("ibm,get-system-parameter"), 3, 1,
>> +				NULL,
>> +				PROCESSOR_MODULE_INFO,
>> +				__pa(rtas_local_data_buf),
>> +				PROCESSOR_MAX_LENGTH);
>> +
>> +	spin_unlock(&rtas_local_data_buf_lock);
> 
> Using this lock this way fails to provide any protection to the data
> buffer or the phys_* variables.
> 
> 
>> +
>> +	if (call_status != 0) {
>> +		pr_info("Error calling get-system-parameter (0x%x)\n",
>> +			call_status);
> 
> To be robust, this should handle busy (-2) and extended delay (990x)
> statuses. And if it's going to log errors it should use pr_err() and use
> decimal, not hex, to report the RTAS call status, since that's how
> they're specified in PAPR+.

Thanks for pointing it, Will update.

Thanks,
Kajol Jain
 

  reply	other threads:[~2020-05-18  5:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-06 11:07 [PATCH v8 0/5] powerpc/hv-24x7: Expose chip/sockets info to add json file metric support for the hv_24x7 socket/chip level events Kajol Jain
2020-05-06 11:07 ` [PATCH v8 1/5] powerpc/perf/hv-24x7: Fix inconsistent output values incase multiple hv-24x7 events run Kajol Jain
2020-05-06 11:07 ` [PATCH v8 2/5] powerpc/hv-24x7: Add rtas call in hv-24x7 driver to get processor details Kajol Jain
2020-05-11 21:07   ` Nathan Lynch
2020-05-18  5:32     ` kajoljain [this message]
2020-05-06 11:07 ` [PATCH v8 3/5] powerpc/hv-24x7: Add sysfs files inside hv-24x7 device to show " Kajol Jain
2020-05-06 11:07 ` [PATCH v8 4/5] Documentation/ABI: Add ABI documentation for chips and sockets Kajol Jain
2020-05-06 11:07 ` [PATCH v8 5/5] powerpc/hv-24x7: Update post_mobility_fixup() to handle migration Kajol Jain
2020-05-08 22:10   ` kbuild test robot
2020-05-08 22:10     ` kbuild test robot
2020-05-11 19:40   ` Nathan Lynch
2020-05-13  6:20     ` kajoljain

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=9c392907-03b2-bd09-51df-41609e802d6c@linux.ibm.com \
    --to=kjain@linux.ibm.com \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=anju@linux.vnet.ibm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jmario@redhat.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.vnet.ibm.com \
    --cc=mamatha4@linux.vnet.ibm.com \
    --cc=mingo@kernel.org \
    --cc=mpetlan@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=nathanl@linux.ibm.com \
    --cc=peterz@infradead.org \
    --cc=ravi.bangoria@linux.ibm.com \
    --cc=suka@us.ibm.com \
    --cc=yao.jin@linux.intel.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.