All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Anthony PERARD" <anthony.perard@vates.tech>
To: "Grygorii Strashko" <gragst.linux@gmail.com>
Cc: xen-devel@lists.xenproject.org,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Julien Grall" <julien@xen.org>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Michal Orzel" <michal.orzel@amd.com>,
	"Roger Pau Monne" <roger.pau@citrix.com>,
	"Jan Beulich" <jbeulich@suse.com>,
	"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
	"Oleksii Moisieiev" <oleksii_moisieiev@epam.com>,
	"Bertrand Marquis" <bertrand.marquis@arm.com>,
	"Juergen Gross" <jgross@suse.com>,
	"Grygorii Strashko" <grygorii_strashko@epam.com>
Subject: Re: [RFC PATCH v3 4/7] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver
Date: Fri, 14 Mar 2025 17:21:43 +0000	[thread overview]
Message-ID: <Z9RlpF7oAACpQdSi@l14> (raw)
In-Reply-To: <20250311111618.1850927-5-grygorii_strashko@epam.com>

On Tue, Mar 11, 2025 at 01:16:15PM +0200, Grygorii Strashko wrote:
> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> index 7edf272386e3..fc6041724a13 100644
> --- a/docs/man/xl.cfg.5.pod.in
> +++ b/docs/man/xl.cfg.5.pod.in
> @@ -3126,6 +3126,21 @@ single SCMI OSPM agent support.
>  Should be used together with B<dom0_scmi_smc_passthrough> Xen command line
>  option.
>  
> +=item B<scmi_smc_multiagent>
> +
> +Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI over
> +SMC calls forwarding from domain to the EL3 firmware (like Trusted Firmware-A)
> +with a multi SCMI OSPM agent support. The SCMI B<agent_id> should be
> +specified for the guest.
> +
> +=back

This new =back shouldn't exist in this patch, because there's no =over
been added. This just fix a bug present in the previous patch.

> +
> +=item B<agent_id=NUMBER>
> +
> +Specifies a non-zero ARM SCI agent id for the guest. This option is mandatory
> +if the SCMI SMC support is enabled for the guest. The agent ids of domains
> +existing on a single host must be unique.

Are they other restriction on what agent_id value can be? I mean from
the description -4242 is a valid value.

>  =back
>  
>  =back
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> index 8e50f6b7c7ac..bc3c64d6ec90 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1091,6 +1091,15 @@ which serves as Driver domain. The SCMI will be disabled for Dom0/hwdom and
>  SCMI nodes removed from Dom0/hwdom device tree.
>  (for example, thin Dom0 with Driver domain use-case).
>  
> +### dom0_scmi_agent_id (ARM)
> +> `= <integer>`
> +
> +The option is available when `CONFIG_SCMI_SMC_MA` is compiled in, and allows to
> +enable SCMI functionality for Dom0 by specifying a non-zero ARM SCMI agent id.
> +The SCMI will be disabled for Dom0 if this option is not specified
> +(for example, thin Dom0 or dom0less use-cases).
> +The agent ids of domains existing on a single host must be unique.
> +
>  ### dtuart (ARM)
>  > `= path [:options]`
>  
> diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
> index d41adea1cefd..cdf5edb299af 100644
> --- a/tools/libs/light/libxl_arm.c
> +++ b/tools/libs/light/libxl_arm.c
> @@ -229,6 +229,10 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>      case LIBXL_ARM_SCI_TYPE_SCMI_SMC:
>          config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC;
>          break;
> +    case LIBXL_ARM_SCI_TYPE_SCMI_SMC_MULTIAGENT:
> +        config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA;
> +        config->arch.arm_sci_agent_id = d_config->b_info.arm_sci.agent_id;
> +        break;
>      default:
>          LOG(ERROR, "Unknown ARM_SCI type %d",
>              d_config->b_info.arm_sci.type);
> diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
> index ea0d30654cdd..e6707c7ca9e7 100644
> --- a/tools/libs/light/libxl_types.idl
> +++ b/tools/libs/light/libxl_types.idl
> @@ -553,11 +553,13 @@ libxl_sve_type = Enumeration("sve_type", [
>  
>  libxl_arm_sci_type = Enumeration("arm_sci_type", [
>      (0, "none"),
> -    (1, "scmi_smc")
> +    (1, "scmi_smc"),
> +    (2, "scmi_smc_multiagent")
>      ], init_val = "LIBXL_ARM_SCI_TYPE_NONE")
>  
>  libxl_arm_sci = Struct("arm_sci", [
>      ("type", libxl_arm_sci_type),
> +    ("agent_id", uint8)

Is it necessary to limit this value to a 8-bit value here? Skimming
through the Xen code, it seems that that value can be 32-bits at times,
but just restricted to 8-bits in the hypercall.

>      ])
>  
>  libxl_rdm_reserve = Struct("rdm_reserve", [
> diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
> index ac9bf0b25c5a..011222ec55b9 100644
> --- a/tools/xl/xl_parse.c
> +++ b/tools/xl/xl_parse.c
> @@ -1324,11 +1327,24 @@ static int parse_arm_sci_config(XLU_Config *cfg, libxl_arm_sci *arm_sci,
>                  tok = ptr + 1;
>              }
>              break;
> +        case STATE_AGENT_ID:
> +            if (*ptr == ',' || *ptr == '\0') {
> +                state = *ptr == ',' ? STATE_OPTION : STATE_TERMINAL;
> +                *ptr = '\0';
> +                arm_sci->agent_id = strtoul(tok, NULL, 0);

You should check that the value returned by strtoul() is actually valid
and does fit in `agent_id`.

> +                tok = ptr + 1;
> +            }
>          default:
>              break;
>          }
>      }
>  
> +    if (arm_sci->type == LIBXL_ARM_SCI_TYPE_SCMI_SMC_MULTIAGENT &&
> +        arm_sci->agent_id == 0) {
> +        fprintf(stderr, "A non-zero ARM_SCI agent_id must be specified\n");
> +        goto parse_error;
> +    }
> +
>      if (tok != ptr || state != STATE_TERMINAL)
>          goto parse_error;
>  
> @@ -3042,6 +3058,7 @@ skip_usbdev:
>          libxl_arm_sci arm_sci = { 0 };
>          if (!parse_arm_sci_config(config, &arm_sci, buf)) {
>              b_info->arm_sci.type = arm_sci.type;
> +            b_info->arm_sci.agent_id = arm_sci.agent_id;

I just realise that it's probably enough to call
parse_arm_sci_config(.., &b_info->arm_sci) instead of declaring
another local `arm_sci` variable. Or is it necessary to have a different
variable somehow?

>          } else {
>              exit(EXIT_FAILURE);
>          }

Thanks,

-- 

Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


  parent reply	other threads:[~2025-03-14 17:22 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-11 11:16 [RFC PATCH v3 0/7] xen/arm: scmi: introduce SCI SCMI SMC multi-agent support Grygorii Strashko
2025-03-11 11:16 ` [RFC PATCH v3 1/7] xen/arm: add generic SCI subsystem Grygorii Strashko
2025-03-11 11:43   ` Jan Beulich
2025-03-24  9:00     ` Oleksii Moisieiev
2025-03-24 10:05       ` Jan Beulich
2025-03-24 13:11         ` Oleksii Moisieiev
2025-03-24 13:43           ` Jan Beulich
2025-03-24 14:25     ` Grygorii Strashko
2025-03-24 14:36       ` Jan Beulich
2025-03-24 15:29         ` Grygorii Strashko
2025-03-13 23:48   ` Stefano Stabellini
2025-03-24 14:26     ` Grygorii Strashko
2025-03-11 11:16 ` [RFC PATCH v3 2/7] xen/arm: scmi-smc: update to be used under sci subsystem Grygorii Strashko
2025-03-13 23:48   ` Stefano Stabellini
2025-03-24 15:08     ` Grygorii Strashko
2025-03-11 11:16 ` [RFC PATCH v3 3/7] xen/arm: scmi-smc: passthrough SCMI SMC to guest domain Grygorii Strashko
2025-03-13 23:48   ` Stefano Stabellini
2025-03-24 16:05     ` Grygorii Strashko
2025-03-14 16:23   ` Anthony PERARD
2025-03-24 16:11     ` Grygorii Strashko
2025-03-11 11:16 ` [RFC PATCH v3 4/7] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Grygorii Strashko
2025-03-13 23:48   ` Stefano Stabellini
2025-03-14 17:21   ` Anthony PERARD [this message]
2025-03-11 11:16 ` [RFC PATCH v3 5/7] libs: libxenhypfs - handle blob properties Grygorii Strashko
2025-03-11 11:26   ` Juergen Gross
2025-03-11 11:16 ` [RFC PATCH v3 6/7] xen/arm: Export host device-tree to hypfs Grygorii Strashko
2025-03-11 11:16 ` [RFC PATCH v3 7/7] xen/arm: scmi: generate scmi dt node for DomUs Grygorii Strashko
2025-03-11 11:46   ` Jan Beulich
2025-03-14 18:28   ` Anthony PERARD
2025-03-21 11:25 ` [RFC PATCH v3 0/7] xen/arm: scmi: introduce SCI SCMI SMC multi-agent support Grygorii Strashko

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=Z9RlpF7oAACpQdSi@l14 \
    --to=anthony.perard@vates.tech \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bertrand.marquis@arm.com \
    --cc=gragst.linux@gmail.com \
    --cc=grygorii_strashko@epam.com \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=oleksii_moisieiev@epam.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.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.