public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Chang, Abner via groups.io" <abner.chang=amd.com@groups.io>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: Nickle Wang <nicklew@nvidia.com>, Igor Kulchytskyy <igork@ami.com>
Subject: Re: [edk2-devel] [edk2-redfish-client][PATCH V2] RedfishClientPkg: Readme.md update
Date: Mon, 5 Feb 2024 07:52:21 +0000	[thread overview]
Message-ID: <LV8PR12MB9452D1E33721953166B034A5EA472@LV8PR12MB9452.namprd12.prod.outlook.com> (raw)
In-Reply-To: <17B0E805BD7B0FC3.13964@groups.io>

[AMD Official Use Only - General]

Hi Nickle and Igor,
In V2, add the requirements for provisioning computer system "Bios" property and BIOS "AttributeRegistry" property.

Thanks
Abner

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Chang,
> Abner via groups.io
> Sent: Monday, February 5, 2024 3:49 PM
> To: devel@edk2.groups.io
> Cc: Nickle Wang <nicklew@nvidia.com>; Igor Kulchytskyy <igork@ami.com>
> Subject: [edk2-devel] [edk2-redfish-client][PATCH V2] RedfishClientPkg:
> Readme.md update
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> From: Abner Chang <abner.chang@amd.com>
>
> Update Readme file to align with Redfish Client
> implementation.
>
> Signed-off-by: Abner Chang <abner.chang@amd.com>
> Cc: Nickle Wang <nicklew@nvidia.com>
> Cc: Igor Kulchytskyy <igork@ami.com>
> ---
>  RedfishClientPkg/Readme.md | 171
> +++++++++++++++++++++++++++++++++----
>  1 file changed, 156 insertions(+), 15 deletions(-)
>
> diff --git a/RedfishClientPkg/Readme.md b/RedfishClientPkg/Readme.md
> index edef2ec23b..23ca160a5a 100644
> --- a/RedfishClientPkg/Readme.md
> +++ b/RedfishClientPkg/Readme.md
> @@ -294,7 +294,7 @@ PCD is set to `TRUE`.
>  The purpose of Redfish feature driver is to do the synchronization job
> between Redfish service and BIOS. The operation of synchronization can be
> simply divided into two types:
>
>  #### Provisioning resource
> -Below is the flow diagram of provisioning platform configuration to Redfish
> service at Bios resource. With the x-uefi-redfish
> +Below is the flow diagram of provisioning platform configuration to Redfish
> service at BIOS resource. With the x-uefi-redfish
>  configure language described in above section, Redfish feature driver collect
> all BIOS attributes from HII database and populated
>  them to Redfish service.
>  ![provisioning](https://github.com/tianocore/edk2-redfish-
> client/blob/main/RedfishClientPkg/Documents/Media/redfish-call-flow-
> provisioning.svg?raw=true)
> @@ -311,7 +311,7 @@ job.
>  Several interfaces defined in EDKII Redfish Resource Config Protocol work
> together to support Redfish synchronization:
>  - Identify()
>    - This function is used to check if the given Redfish resource is the one the
> feature driver wants to manage. A platform
> -    library `RedfishReesourceIdentifyLib` is introduced for platform to
> implement its own policy to identify Redfish resource.
> +    library `RedfishResourceIdentifyLib` is introduced for platform to
> implement its own policy to identify Redfish resource.
>  - Check()
>    - This function is used to check the attribute status on Redfish service. If all
> attributes the feature driver manages
>      are presented in Redfish service, feature driver must provision them already.
> Otherwise, Provisioning() will be called
> @@ -338,19 +338,160 @@ struct
> _EDKII_REDFISH_RESOURCE_ADDENDUM_PROTOCOL {
>  };
>  ```
>
> -#### Redfish service implementation
> -The idea of Redfish synchronization design is to manage Redfish resource
> directly by platform firmware. To do this, Redfish
> -synchronization functions have to work with Redfish service implementation
> in BMC firmware. This is because the interface
> -between platform firmware and BMC firmware is not defined in any
> specification.
> -Several prerequisites must be satisfied:
> -- Platform firmware has permission to manage Redfish resource. BMC has
> ability to tell the difference between platform request
> -  and out-of-band user. This can normally be done by identifying the
> bootstrap account in HTTP request. The bootstrap account is
> -  described in Host Interface specification 1.3.0 section 9.
> -- The ability to tell if there is an user who changes to Redfish resource or not.
> Redfish feature drivers can only be executed at
> -  POST time. So the modification to BIOS managed resource is an
> asynchronous operation. Thus, we need below supports in Redfish service:
> -  - ETAG support in HTTP header.
> -  - Setting resource support (defined in Redfish specification 1.18 section
> 9.10).
> -  - Redfish Task support to POST and DELETE operation made by user in
> Redfish collection resource and Redfish actions.
> +### Redfish Service Implementation that Incorporates with EDK2 Redfish
> +The idea of Redfish synchronization design is to manage Redfish resource
> directly by platform host
> +firmware. To do this, Redfish synchronization functions have to work with
> Redfish service implementation
> +in BMC firmware. This is because the mechanism between platform host
> firmware and BMC firmware is not
> +defined in any specification. Several prerequisites must be satisfied and listed
> below:
> +
> +**BIOS Redfish Credential**
> +
> +- Platform host firmware has the permission to manage Redfish resource.
> BMC has ability to distinguish
> +the in-band platform host firmware and out-of-band user, this can normally
> be done by identifying the bootstrap account in HTTP request. The bootstrap
> account is described in Host Interface specification 1.3.0 section 9. If the
> Redfish client uses bootstrap account for HTTP actions, BMC must consider
> the Redfish
> +client is BIOS and give the write permission to BIOS for updating BIOS
> managed Redfish properties even the
> +properties are declared as "ReadOnly" in the Redfish schema.
> +
> +**BIOS Managed Redfish Resource Provisioning**
> +- The Default Empty BIOS Managed Redfish Resource <br>
> +  The BIOS managed Redfish properties may not covering the entire resource
> but just manages some properties
> +  in the resource or a subset of resource. For example, the "Boot" property in
> ComputerSystem. BIOS is not able to use HTTP PUT to replace a resource that
> is not entirely managed by BIOS. The HTTP PATCH is the only method to
> provision the BIOS managed properties. This is a requirement the BIOS
> managed properties
> +  in the resource must have either a default value or an empty property, with
> this BIOS can have a HTTP
> +  PATCH to update the value.<br><br>
> +  For the example in ComputerSystem resource below,<br>
> +  The "BootOrder" property is exist in ComputerSystem, however the values is
> left as empty. With the
> +  existence of "BootOrder", BIOS can provision the valid values using HTTP
> PATCH with out error.
> +
> +```C
> +In Redfish Computer System resource:
> +{
> +  "Boot": {
> +    "AutomaticRetryAttempts": 3,
> +    "BootOrder": []
> +  }
> +}
> +```
> +
> +- Computer System Bios resource<br>
> +The "Bios" property in Computer System resource usually has a "@odata.id"
> property that is an
> +URI points to the BIOS Redfish resource. The "Bios" property must exist in the
> computer system
> +resource and the URI of "Bios" property is required to be provided by BMC as
> the default value.
> +With this, BIOS knows where to provision the BIOS resource.
> +
> +```C
> +In Redfish Computer System resource:
> +{
> +  "Bios": {
> +    "@odata.id": "/redfish/v1/Systems/system/Bios"
> +  }
> +}
> +```
> +
> +- BIOS AttributeRegistry<br>
> +The "AttributeRegistry" is a property in "Bios" resource, which is the resource
> ID of
> +message registry file that has the system-specific information about a BIOS
> resource.
> +"AttributeRegistry" must exist in "Bios" resource and the value can't be empty
> if the the
> +platform support system-specific information BIOS resource. In order to
> provision the BIOS
> +attribute registry resource, BIOS attribute registry must be defined as a
> collection member
> +in the service root "Registries" collection property. The value of "Id" property
> in
> +MessageFileRegistry must be as the same as "AttributeRegistry" value in BIOS
> resource.
> +Also, the "Languages" and "Location" array property must be predefined in
> the Redfish message
> +file. The location URI of message registry file can be determined by BMC.
> With this, BIOS can get the resource ID from "AttributeRegistry" property and
> look for the same ID defined in the
> +Message File Registry collection for provisioning the entire BIOS
> AttributeRegistry resource.
> +
> +```C
> +In Redfish Computer System Bios resource:
> +{
> +  "AttributeRegistry": "BiosAttributeRegistry"
> +}
> +
> +In Service Root Registries resource:
> +{
> +  "Members": [
> +    {
> +      "@odata.id": "/redfish/v1/Registries/BiosAttributeRegistry"
> +    }
> +  ]
> +}
> +
> +In /redfish/v1/Registries/BiosAttributeRegistry:
> +{
> +  "Id": "BiosAttributeRegistry",
> +  "Languages": [
> +    "en"
> +  ],
> +  "Languages@odata.count": 1,
> +  "Location": [
> +    {
> +      "Language": "en",
> +      "Uri": "/redfish/v1/Registries/Bios"
> +    }
> +  ]
> +}
> +
> +The URI "/redfish/v1/Registries/Bios" is where BIOS to put the BIOS attribute
> registry resource.
> +```
> +
> +**BIOS Managed Redfish Resource Consumption**
> +
> +The ability to tell if there are the changes on BIOS managed Redfish resource.
> The modifications to BIOS managed resource is considered as an
> asynchronous operation because the Redfish feature drivers can only be
> +executed at the platform host firmware POST time. With the above
> constraint, we need the below requirements
> +on BMC Redfish service.
> +  - ETAG Support in HTTP Header<br>
> +  To reduce the unnecessary HTTP GET for the unchanged Redfish resource
> that leads to increase the platform
> +  boot time, ETAG is leveraged to tell BIOS if BIOS has to get the entire
> resource as there were some
> +  changes made on the resource. Although ETAG support in HTTP response
> header is not mandatory by edk2
> +  Redfish design, it is still a strong recommendation if the platform boot time
> is a concern. <br>
> +  Below PCD is used to configure the BMC Redfish service supports ETAG.
> +
> +```C
> +  gEfiRedfishClientPkgTokenSpaceGuid.PcdRedfishServiceEtagSupported
> +```
> +
> +  - HTTP Query Head Support<br>
> +  In order to retrieve the HTTP response headers only to reduce the
> unnecessary HTTP GET for the entire
> +  Redfish resource. HTTP Query Head support on Redfish service is mandatory
> if the system boot time is a
> +  concern.
> +
> +  - Redfish Setting Annotation Support (defined in Redfish specification 1.18
> section 9.10).<br>
> +  @Redfish.Settings annotation represents the future state of resource. The
> future state of BIOS managed
> +  properties will be consume in the next time platform boot, no matter it is a
> reset cycle or power cycle.<br>
> +  This is a requirement for BMC Redfish service having @Redfish.Settings for
> the changed properties made by
> +  remote user. With the @Redfish.Settings annotation in the resource, BIOS
> can identify which Redfish
> +  properties were changed.  BIOS can then only consume these changes and
> apply those to BIOS platform
> +  configurations. Without providing @Redfish.Settings for the changes, BIOS
> can just consume all of the
> +  BIOS managed properties on Redfish service even the properties weren't
> changed.
> +
> +  - ETAG Support in Redfish Setting Annotation<br>
> +  ETAG in @Redfish.Settings resource is also required. As @Redfish.Settings
> annotation may not be deleted by
> +  BMC after it has been consumed, the out of date @Redfish.Settings may still
> leave in the Redfish
> +  resource. With ETAG is provided in @Redfish.Settings, BIOS is able to tell if
> @Redfish.Settings is fresh
> +  or stale.<br><br>
> +  Below is the example of @Redfish.Settings for BIOS attribute change,
> +
> +```C
> +  "@Redfish.Settings": {
> +    "@odata.type": "#Settings.v1_3_3.Settings",
> +    "SettingsObject": {
> +      "@odata.id": "/redfish/v1/Systems/1/Bios",
> +      "@odata.etag": "W/\"ABCDEFG\"",
> +      "Attributes": {
> +        "BootMode": "Uefi"
> +      }
> +    }
> +  }
> +```
> +
> +**Redfish HTTP Content Encoding**<br>
> +For the performance consideration when BIOS HTTP POST, PUT and PATCH
> the resource, HTTP Content-Encoding
> +header is leverage to compress the resource to reduce the payload size with
> BMC Redfish support. Below PCD string is introduced for platform developer
> to set the encoding method supported by BMC Redfish, currently
> +only "None" and "gzip" are supported.
> +
> +```C
> +
> gEfiRedfishPkgTokenSpaceGuid.PcdRedfishServiceContentEncoding|["None"][
> "gzip"]
> +```
> +
> +**BIOS Redfish Action**
> + - Redfish Task support to POST and DELETE operation made by user in
> Redfish collection resource and Redfish actions.
>
>  ### Redfish Task design
>  TBD.
> --
> 2.37.1.windows.1
>
>
>
> 
>



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115102): https://edk2.groups.io/g/devel/message/115102
Mute This Topic: https://groups.io/mt/104172106/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



       reply	other threads:[~2024-02-05  7:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <17B0E805BD7B0FC3.13964@groups.io>
2024-02-05  7:52 ` Chang, Abner via groups.io [this message]
2024-02-05  7:49 [edk2-devel] [edk2-redfish-client][PATCH V2] RedfishClientPkg: Readme.md update Chang, Abner via groups.io
2024-02-06 17:28 ` Igor Kulchytskyy via groups.io

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-list 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=LV8PR12MB9452D1E33721953166B034A5EA472@LV8PR12MB9452.namprd12.prod.outlook.com \
    --to=devel@edk2.groups.io \
    /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