Re: [PATCH v3 1/1] powerpc/pseries: Interface to represent PAPR firmware attributes
On 16/07/21 1:16 am, Fabiano Rosas wrote:
Pratik Sampat writes:
Hello,
On 12/07/21 9:13 pm, Fabiano Rosas wrote:
"Pratik R. Sampat" writes:
Hi, have you seen Documentation/core-api/kobject.rst, particularly the
part that says:
"When you see a sysfs directory full of other directories, generally each
of those directories corresponds to a kobject in the same kset."
Taking a look at samples/kobject/kset-example.c, it seems to provide an
overall structure that is closer to what other modules do when creating
sysfs entries. It uses less dynamic allocations and deals a bit better
with cleaning up the state afterwards.
Thank you for pointing me towards this example, the kset approach is
interesting and the example indeed does handle cleanups better.
Currently, we use "machine_device_initcall()" to register this
functionality, do you suggest I convert this into a tristate module
instead where I can include a "module_exit" for cleanups?
Ugh.. I was hoping we could get away with having all cleanups done at
kobject release time. But now I see that it is not called unless we
decrement the reference count. Nevermind then.
Sure I can keep the current approach as-is, while incorporating the rest of your
comments.
+ ret = plpar_hcall_norets(H_GET_ENERGY_SCALE_INFO, ESI_FLAGS_ALL, 0,
+virt_to_phys(esi_buf), MAX_BUF_SZ);
+ esi_hdr = (struct h_energy_scale_info_hdr *) esi_buf;
+ if (ret != H_SUCCESS || esi_hdr->data_header_version != ESI_VERSION) {
I really dislike this. If you want to bail due to version change, then
at least include in the ABI document that we might not give the
userspace any data at all.
My only concern for having a version check is that, the attribute list
can change as well as the attributes itself may change.
If that is the case, then in a newer version if we do not bail out we
may parse data into our structs incorrectly.
Sure, that is a valid concern. But the documentation for the header
version field says:
"Version of the Header. The header will be always backward compatible,
and changes will not impact the Array of attributes. Current version =
0x01"
I guess this is a bit vague still, but I understood that:
1- header elements continue to exist at the same position;
2- the format of the array of attributes will not change.
Are you saying that my interpretation above is not correct or that you
don't trust the HV to enforce it?
Thanks for the clarification.
I understand now that my interpretation was incorrect. The version change
should not break anything as our code in kernel acts just as a pass through.
My argument only hinges on that we should likely give no data at all
instead of junk or incorrect data.
I agree. I just don't think it would be possible to end up with
incorrect data, unless the HV has a bug.
Maybe I could make this check after the return check and give out a
version mismatch message like the following?
pr_warn("hcall failed: H_GET_ENERGY_SCALE_INFO VER MISMATCH - EXP: 0x%x, REC:
0x%x",
ESI_VERSION, esi_hdr->data_header_version);
Yes, this will help with debug if we ever end up in this situation.
Understood, In case of a version mismatch and IDs are introduced, it can help
the userspace know that something has changed.
+ pr_warn("hcall failed: H_GET_ENERGY_SCALE_INFO");
+ goto out;
+ }
+
+ num_attrs = be64_to_cpu(esi_hdr->num_attrs);
+ /*
+* Typecast the energy buffer to the attribute structure at the offset
+* specified in the buffer
+*/
I think the code is now simple enough that this comment could be
removed.
ack
+ esi_attrs = (struct energy_scale_attribute *)
+ (esi_buf + be64_to_cpu(esi_hdr->array_offset));
+
+ pgs = kcalloc(num_attrs, sizeof(*pgs), GFP_KERNEL);
This is never freed.
+ if (!pgs)
+ goto out_pgs;
+
+ papr_kobj = kobject_create_and_add("papr", firmware_kobj);
+ if (!papr_kobj) {
+ pr_warn("kobject_create_and_add papr failed\n");
+ goto out_kobj;
+ }
+
+ esi_kobj = kobject_create_and_add("energy_scale_info", papr_kobj);
+ if (!esi_kobj) {
+ pr_warn("kobject_create_and_add energy_scale_info failed\n");
+ goto out_ekobj;
+ }
+
+ for (idx = 0; idx < num_attrs; idx++) {
+ char buf[4];
+ bool show_val_desc = true;
+
+ pgs[idx].pgattrs = kcalloc(MAX_ATTRS,
+ sizeof(*pgs[idx].pgattrs),
+ GFP_KERNEL);
+ if (!pgs[idx].pgattrs)
+ goto out_kobj;
+
+ pgs[idx].pg.attrs = kcalloc(MAX_ATTRS + 1,
+ sizeof(*pgs[idx].pg.attrs),
+ GFP_KERNEL);
I think the kobject code expects this to be statically
Re: [PATCH v3 1/1] powerpc/pseries: Interface to represent PAPR firmware attributes
Pratik Sampat writes:
> Hello,
>
> On 12/07/21 9:13 pm, Fabiano Rosas wrote:
>> "Pratik R. Sampat" writes:
>>
>> Hi, have you seen Documentation/core-api/kobject.rst, particularly the
>> part that says:
>>
>> "When you see a sysfs directory full of other directories, generally each
>> of those directories corresponds to a kobject in the same kset."
>>
>> Taking a look at samples/kobject/kset-example.c, it seems to provide an
>> overall structure that is closer to what other modules do when creating
>> sysfs entries. It uses less dynamic allocations and deals a bit better
>> with cleaning up the state afterwards.
>>
> Thank you for pointing me towards this example, the kset approach is
> interesting and the example indeed does handle cleanups better.
>
> Currently, we use "machine_device_initcall()" to register this
> functionality, do you suggest I convert this into a tristate module
> instead where I can include a "module_exit" for cleanups?
Ugh.. I was hoping we could get away with having all cleanups done at
kobject release time. But now I see that it is not called unless we
decrement the reference count. Nevermind then.
>>> + ret = plpar_hcall_norets(H_GET_ENERGY_SCALE_INFO, ESI_FLAGS_ALL, 0,
>>> +virt_to_phys(esi_buf), MAX_BUF_SZ);
>>> + esi_hdr = (struct h_energy_scale_info_hdr *) esi_buf;
>>> + if (ret != H_SUCCESS || esi_hdr->data_header_version != ESI_VERSION) {
>> I really dislike this. If you want to bail due to version change, then
>> at least include in the ABI document that we might not give the
>> userspace any data at all.
>
> My only concern for having a version check is that, the attribute list
> can change as well as the attributes itself may change.
> If that is the case, then in a newer version if we do not bail out we
> may parse data into our structs incorrectly.
Sure, that is a valid concern. But the documentation for the header
version field says:
"Version of the Header. The header will be always backward compatible,
and changes will not impact the Array of attributes. Current version =
0x01"
I guess this is a bit vague still, but I understood that:
1- header elements continue to exist at the same position;
2- the format of the array of attributes will not change.
Are you saying that my interpretation above is not correct or that you
don't trust the HV to enforce it?
> My argument only hinges on that we should likely give no data at all
> instead of junk or incorrect data.
I agree. I just don't think it would be possible to end up with
incorrect data, unless the HV has a bug.
> Maybe I could make this check after the return check and give out a
> version mismatch message like the following?
> pr_warn("hcall failed: H_GET_ENERGY_SCALE_INFO VER MISMATCH - EXP: 0x%x, REC:
> 0x%x",
> ESI_VERSION, esi_hdr->data_header_version);
Yes, this will help with debug if we ever end up in this situation.
>>> + pr_warn("hcall failed: H_GET_ENERGY_SCALE_INFO");
>>> + goto out;
>>> + }
>>> +
>>> + num_attrs = be64_to_cpu(esi_hdr->num_attrs);
>>> + /*
>>> +* Typecast the energy buffer to the attribute structure at the offset
>>> +* specified in the buffer
>>> +*/
>> I think the code is now simple enough that this comment could be
>> removed.
>
> ack
>
>>> + esi_attrs = (struct energy_scale_attribute *)
>>> + (esi_buf + be64_to_cpu(esi_hdr->array_offset));
>>> +
>>> + pgs = kcalloc(num_attrs, sizeof(*pgs), GFP_KERNEL);
>> This is never freed.
>>
>>> + if (!pgs)
>>> + goto out_pgs;
>>> +
>>> + papr_kobj = kobject_create_and_add("papr", firmware_kobj);
>>> + if (!papr_kobj) {
>>> + pr_warn("kobject_create_and_add papr failed\n");
>>> + goto out_kobj;
>>> + }
>>> +
>>> + esi_kobj = kobject_create_and_add("energy_scale_info", papr_kobj);
>>> + if (!esi_kobj) {
>>> + pr_warn("kobject_create_and_add energy_scale_info failed\n");
>>> + goto out_ekobj;
>>> + }
>>> +
>>> + for (idx = 0; idx < num_attrs; idx++) {
>>> + char buf[4];
>>> + bool show_val_desc = true;
>>> +
>>> + pgs[idx].pgattrs = kcalloc(MAX_ATTRS,
>>> + sizeof(*pgs[idx].pgattrs),
>>> + GFP_KERNEL);
>>> + if (!pgs[idx].pgattrs)
>>> + goto out_kobj;
>>> +
>>> + pgs[idx].pg.attrs = kcalloc(MAX_ATTRS + 1,
>>> + sizeof(*pgs[idx].pg.attrs),
>>> + GFP_KERNEL);
>> I think the kobject code expects this to be statically allocated, so
>> you'd need to override the release function in some way to be able to
>> free this.
>
> Right this and pgs both are never free'd because my understanding was
> that as this functionality is invoked from machine_init, I'd expect it
> to stay until shutdown.
Yep, I thought the kset code would improve this, but I misread
Re: [PATCH v3 1/1] powerpc/pseries: Interface to represent PAPR firmware attributes
Hello, On 12/07/21 9:13 pm, Fabiano Rosas wrote: "Pratik R. Sampat" writes: Hi, have you seen Documentation/core-api/kobject.rst, particularly the part that says: "When you see a sysfs directory full of other directories, generally each of those directories corresponds to a kobject in the same kset." Taking a look at samples/kobject/kset-example.c, it seems to provide an overall structure that is closer to what other modules do when creating sysfs entries. It uses less dynamic allocations and deals a bit better with cleaning up the state afterwards. Thank you for pointing me towards this example, the kset approach is interesting and the example indeed does handle cleanups better. Currently, we use "machine_device_initcall()" to register this functionality, do you suggest I convert this into a tristate module instead where I can include a "module_exit" for cleanups? Adds a generic interface to represent the energy and frequency related PAPR attributes on the system using the new H_CALL "H_GET_ENERGY_SCALE_INFO". H_GET_EM_PARMS H_CALL was previously responsible for exporting this information in the lparcfg, however the H_GET_EM_PARMS H_CALL will be deprecated P10 onwards. The H_GET_ENERGY_SCALE_INFO H_CALL is of the following call format: hcall( uint64 H_GET_ENERGY_SCALE_INFO, // Get energy scale info uint64 flags, // Per the flag request uint64 firstAttributeId,// The attribute id uint64 bufferAddress, // Guest physical address of the output buffer uint64 bufferSize // The size in bytes of the output buffer ); This H_CALL can query either all the attributes at once with firstAttributeId = 0, flags = 0 as well as query only one attribute at a time with firstAttributeId = id, flags = 1. The output buffer consists of the following 1. number of attributes - 8 bytes 2. array offset to the data location - 8 bytes 3. version info - 1 byte 4. A data array of size num attributes, which contains the following: a. attribute ID - 8 bytes b. attribute value in number - 8 bytes c. attribute name in string - 64 bytes d. attribute value in string - 64 bytes The new H_CALL exports information in direct string value format, hence a new interface has been introduced in /sys/firmware/papr/energy_scale_info to export this information to userspace in an extensible pass-through format. The H_CALL returns the name, numeric value and string value (if exists) The format of exposing the sysfs information is as follows: /sys/firmware/papr/energy_scale_info/ |-- / |-- desc |-- value |-- value_desc (if exists) |-- / |-- desc |-- value |-- value_desc (if exists) ... The energy information that is exported is useful for userspace tools such as powerpc-utils. Currently these tools infer the "power_mode_data" value in the lparcfg, which in turn is obtained from the to be deprecated H_GET_EM_PARMS H_CALL. On future platforms, such userspace utilities will have to look at the data returned from the new H_CALL being populated in this new sysfs interface and report this information directly without the need of interpretation. Signed-off-by: Pratik R. Sampat Reviewed-by: Gautham R. Shenoy --- .../sysfs-firmware-papr-energy-scale-info | 26 ++ arch/powerpc/include/asm/hvcall.h | 24 +- arch/powerpc/kvm/trace_hv.h | 1 + arch/powerpc/platforms/pseries/Makefile | 3 +- .../pseries/papr_platform_attributes.c| 320 ++ 5 files changed, 372 insertions(+), 2 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info create mode 100644 arch/powerpc/platforms/pseries/papr_platform_attributes.c diff --git a/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info b/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info new file mode 100644 index ..fd82f2bfafe5 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info @@ -0,0 +1,26 @@ +What: /sys/firmware/papr/energy_scale_info +Date: June 2021 +Contact: Linux for PowerPC mailing list +Description: Directory hosting a set of platform attributes like + energy/frequency on Linux running as a PAPR guest. + + Each file in a directory contains a platform + attribute hierarchy pertaining to performance/ + energy-savings mode and processor frequency. + +What: /sys/firmware/papr/energy_scale_info/ + /sys/firmware/papr/energy_scale_info//desc + /sys/firmware/papr/energy_scale_info//value + /sys/firmware/papr/energy_scale_info//value_desc +Date: June 2021 +Contact: Linux for PowerPC mailing list +Description: Energy, frequency attributes directory for POWERVM servers + + This directory provides energy, erequency,
Re: [PATCH v3 1/1] powerpc/pseries: Interface to represent PAPR firmware attributes
"Pratik R. Sampat" writes: Hi, have you seen Documentation/core-api/kobject.rst, particularly the part that says: "When you see a sysfs directory full of other directories, generally each of those directories corresponds to a kobject in the same kset." Taking a look at samples/kobject/kset-example.c, it seems to provide an overall structure that is closer to what other modules do when creating sysfs entries. It uses less dynamic allocations and deals a bit better with cleaning up the state afterwards. > Adds a generic interface to represent the energy and frequency related > PAPR attributes on the system using the new H_CALL > "H_GET_ENERGY_SCALE_INFO". > > H_GET_EM_PARMS H_CALL was previously responsible for exporting this > information in the lparcfg, however the H_GET_EM_PARMS H_CALL > will be deprecated P10 onwards. > > The H_GET_ENERGY_SCALE_INFO H_CALL is of the following call format: > hcall( > uint64 H_GET_ENERGY_SCALE_INFO, // Get energy scale info > uint64 flags, // Per the flag request > uint64 firstAttributeId,// The attribute id > uint64 bufferAddress, // Guest physical address of the output buffer > uint64 bufferSize // The size in bytes of the output buffer > ); > > This H_CALL can query either all the attributes at once with > firstAttributeId = 0, flags = 0 as well as query only one attribute > at a time with firstAttributeId = id, flags = 1. > > The output buffer consists of the following > 1. number of attributes - 8 bytes > 2. array offset to the data location - 8 bytes > 3. version info - 1 byte > 4. A data array of size num attributes, which contains the following: > a. attribute ID - 8 bytes > b. attribute value in number - 8 bytes > c. attribute name in string - 64 bytes > d. attribute value in string - 64 bytes > > The new H_CALL exports information in direct string value format, hence > a new interface has been introduced in > /sys/firmware/papr/energy_scale_info to export this information to > userspace in an extensible pass-through format. > > The H_CALL returns the name, numeric value and string value (if exists) > > The format of exposing the sysfs information is as follows: > /sys/firmware/papr/energy_scale_info/ >|-- / > |-- desc > |-- value > |-- value_desc (if exists) >|-- / > |-- desc > |-- value > |-- value_desc (if exists) > ... > > The energy information that is exported is useful for userspace tools > such as powerpc-utils. Currently these tools infer the > "power_mode_data" value in the lparcfg, which in turn is obtained from > the to be deprecated H_GET_EM_PARMS H_CALL. > On future platforms, such userspace utilities will have to look at the > data returned from the new H_CALL being populated in this new sysfs > interface and report this information directly without the need of > interpretation. > > Signed-off-by: Pratik R. Sampat > Reviewed-by: Gautham R. Shenoy > --- > .../sysfs-firmware-papr-energy-scale-info | 26 ++ > arch/powerpc/include/asm/hvcall.h | 24 +- > arch/powerpc/kvm/trace_hv.h | 1 + > arch/powerpc/platforms/pseries/Makefile | 3 +- > .../pseries/papr_platform_attributes.c| 320 ++ > 5 files changed, 372 insertions(+), 2 deletions(-) > create mode 100644 > Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info > create mode 100644 arch/powerpc/platforms/pseries/papr_platform_attributes.c > > diff --git a/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info > b/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info > new file mode 100644 > index ..fd82f2bfafe5 > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info > @@ -0,0 +1,26 @@ > +What:/sys/firmware/papr/energy_scale_info > +Date:June 2021 > +Contact: Linux for PowerPC mailing list > +Description: Directory hosting a set of platform attributes like > + energy/frequency on Linux running as a PAPR guest. > + > + Each file in a directory contains a platform > + attribute hierarchy pertaining to performance/ > + energy-savings mode and processor frequency. > + > +What:/sys/firmware/papr/energy_scale_info/ > + /sys/firmware/papr/energy_scale_info//desc > + /sys/firmware/papr/energy_scale_info//value > + /sys/firmware/papr/energy_scale_info//value_desc > +Date:June 2021 > +Contact: Linux for PowerPC mailing list > +Description: Energy, frequency attributes directory for POWERVM servers > + > + This directory provides energy, erequency, folding information. > It s/erequency/frequency/ > + contains below sysfs attributes: > + > + - desc: String description of the attribute > + > + - value: Numeric value of attribute >
[PATCH v3 1/1] powerpc/pseries: Interface to represent PAPR firmware attributes
Adds a generic interface to represent the energy and frequency related
PAPR attributes on the system using the new H_CALL
"H_GET_ENERGY_SCALE_INFO".
H_GET_EM_PARMS H_CALL was previously responsible for exporting this
information in the lparcfg, however the H_GET_EM_PARMS H_CALL
will be deprecated P10 onwards.
The H_GET_ENERGY_SCALE_INFO H_CALL is of the following call format:
hcall(
uint64 H_GET_ENERGY_SCALE_INFO, // Get energy scale info
uint64 flags, // Per the flag request
uint64 firstAttributeId,// The attribute id
uint64 bufferAddress, // Guest physical address of the output buffer
uint64 bufferSize // The size in bytes of the output buffer
);
This H_CALL can query either all the attributes at once with
firstAttributeId = 0, flags = 0 as well as query only one attribute
at a time with firstAttributeId = id, flags = 1.
The output buffer consists of the following
1. number of attributes - 8 bytes
2. array offset to the data location - 8 bytes
3. version info - 1 byte
4. A data array of size num attributes, which contains the following:
a. attribute ID - 8 bytes
b. attribute value in number - 8 bytes
c. attribute name in string - 64 bytes
d. attribute value in string - 64 bytes
The new H_CALL exports information in direct string value format, hence
a new interface has been introduced in
/sys/firmware/papr/energy_scale_info to export this information to
userspace in an extensible pass-through format.
The H_CALL returns the name, numeric value and string value (if exists)
The format of exposing the sysfs information is as follows:
/sys/firmware/papr/energy_scale_info/
|-- /
|-- desc
|-- value
|-- value_desc (if exists)
|-- /
|-- desc
|-- value
|-- value_desc (if exists)
...
The energy information that is exported is useful for userspace tools
such as powerpc-utils. Currently these tools infer the
"power_mode_data" value in the lparcfg, which in turn is obtained from
the to be deprecated H_GET_EM_PARMS H_CALL.
On future platforms, such userspace utilities will have to look at the
data returned from the new H_CALL being populated in this new sysfs
interface and report this information directly without the need of
interpretation.
Signed-off-by: Pratik R. Sampat
Reviewed-by: Gautham R. Shenoy
---
.../sysfs-firmware-papr-energy-scale-info | 26 ++
arch/powerpc/include/asm/hvcall.h | 24 +-
arch/powerpc/kvm/trace_hv.h | 1 +
arch/powerpc/platforms/pseries/Makefile | 3 +-
.../pseries/papr_platform_attributes.c| 320 ++
5 files changed, 372 insertions(+), 2 deletions(-)
create mode 100644
Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info
create mode 100644 arch/powerpc/platforms/pseries/papr_platform_attributes.c
diff --git a/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info
b/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info
new file mode 100644
index ..fd82f2bfafe5
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info
@@ -0,0 +1,26 @@
+What: /sys/firmware/papr/energy_scale_info
+Date: June 2021
+Contact: Linux for PowerPC mailing list
+Description: Directory hosting a set of platform attributes like
+ energy/frequency on Linux running as a PAPR guest.
+
+ Each file in a directory contains a platform
+ attribute hierarchy pertaining to performance/
+ energy-savings mode and processor frequency.
+
+What: /sys/firmware/papr/energy_scale_info/
+ /sys/firmware/papr/energy_scale_info//desc
+ /sys/firmware/papr/energy_scale_info//value
+ /sys/firmware/papr/energy_scale_info//value_desc
+Date: June 2021
+Contact: Linux for PowerPC mailing list
+Description: Energy, frequency attributes directory for POWERVM servers
+
+ This directory provides energy, erequency, folding information.
It
+ contains below sysfs attributes:
+
+ - desc: String description of the attribute
+
+ - value: Numeric value of attribute
+
+ - value_desc: String value of attribute
diff --git a/arch/powerpc/include/asm/hvcall.h
b/arch/powerpc/include/asm/hvcall.h
index e3b29eda8074..c91714ea6719 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -316,7 +316,8 @@
#define H_SCM_PERFORMANCE_STATS 0x418
#define H_RPT_INVALIDATE 0x448
#define H_SCM_FLUSH0x44C
-#define MAX_HCALL_OPCODE H_SCM_FLUSH
+#define H_GET_ENERGY_SCALE_INFO0x450
+#define MAX_HCALL_OPCODE H_GET_ENERGY_SCALE_INFO
/* Scope args for H_SCM_UNBIND_ALL */
#define H_UNBIND_SCOPE_ALL (0x1)
@@ -631,6 +632,27 @@ struct hv_gpci_request_buffer {
uint8_t bytes[HGPCI_MAX_DATA_BYTES];
} __packed;
