[PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Daniele Alessandrelli]

From: Daniele Alessandrelli <daniele.alessandrelli@intel.com>

Currently, when SMC/HVC is used as transport, the base address of the
shared memory used for communication is not passed to the SMCCC call.
This means that such an address must be hard-coded into the bootloader.

In order to increase flexibility and allow the memory layout to be
changed without modifying the bootloader, this patch adds the shared
memory base address to the a1 argument of the SMCCC call.

On the Secure Monitor side, the service call implementation can
therefore read the a1 argument in order to know the location of the
shared memory to use. This change is backward compatible to existing
service call implementations as long as they don't check for a1 to be
zero.

Signed-off-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
Signed-off-by: Paul J. Murphy <paul.j.murphy@intel.com>
---
 drivers/firmware/arm_scmi/smc.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/smc.c
index 49bc4b0e8428..aef3a58f8266 100644
--- a/drivers/firmware/arm_scmi/smc.c
+++ b/drivers/firmware/arm_scmi/smc.c
@@ -21,12 +21,14 @@
  *
  * @cinfo: SCMI channel info
  * @shmem: Transmit/Receive shared memory area
+ * @shmem_paddr: Physical address of shmem
  * @func_id: smc/hvc call function id
  */
 
 struct scmi_smc {
 	struct scmi_chan_info *cinfo;
 	struct scmi_shared_mem __iomem *shmem;
+	resource_size_t shmem_paddr;
 	struct mutex shmem_lock;
 	u32 func_id;
 };
@@ -73,6 +75,7 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo, struct device *dev,
 		dev_err(dev, "failed to ioremap SCMI Tx shared memory\n");
 		return -EADDRNOTAVAIL;
 	}
+	scmi_info->shmem_paddr = res.start;
 
 	ret = of_property_read_u32(dev->of_node, "arm,smc-id", &func_id);
 	if (ret < 0)
@@ -109,7 +112,8 @@ static int smc_send_message(struct scmi_chan_info *cinfo,
 
 	shmem_tx_prepare(scmi_info->shmem, xfer);
 
-	arm_smccc_1_1_invoke(scmi_info->func_id, 0, 0, 0, 0, 0, 0, 0, &res);
+	arm_smccc_1_1_invoke(scmi_info->func_id, scmi_info->shmem_paddr, 0, 0,
+			     0, 0, 0, 0, &res);
 	scmi_rx_callback(scmi_info->cinfo, shmem_read_header(scmi_info->shmem));
 
 	mutex_unlock(&scmi_info->shmem_lock);
-- 
2.26.2

[PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Daniele Alessandrelli]

From: Daniele Alessandrelli <daniele.alessandrelli@intel.com>

Currently, when SMC/HVC is used as transport, the base address of the
shared memory used for communication is not passed to the SMCCC call.
This means that such an address must be hard-coded into the bootloader.

In order to increase flexibility and allow the memory layout to be
changed without modifying the bootloader, this patch adds the shared
memory base address to the a1 argument of the SMCCC call.

On the Secure Monitor side, the service call implementation can
therefore read the a1 argument in order to know the location of the
shared memory to use. This change is backward compatible to existing
service call implementations as long as they don't check for a1 to be
zero.

Signed-off-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
Signed-off-by: Paul J. Murphy <paul.j.murphy@intel.com>
---
 drivers/firmware/arm_scmi/smc.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/smc.c
index 49bc4b0e8428..aef3a58f8266 100644
--- a/drivers/firmware/arm_scmi/smc.c
+++ b/drivers/firmware/arm_scmi/smc.c
@@ -21,12 +21,14 @@
  *
  * @cinfo: SCMI channel info
  * @shmem: Transmit/Receive shared memory area
+ * @shmem_paddr: Physical address of shmem
  * @func_id: smc/hvc call function id
  */
 
 struct scmi_smc {
 	struct scmi_chan_info *cinfo;
 	struct scmi_shared_mem __iomem *shmem;
+	resource_size_t shmem_paddr;
 	struct mutex shmem_lock;
 	u32 func_id;
 };
@@ -73,6 +75,7 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo, struct device *dev,
 		dev_err(dev, "failed to ioremap SCMI Tx shared memory\n");
 		return -EADDRNOTAVAIL;
 	}
+	scmi_info->shmem_paddr = res.start;
 
 	ret = of_property_read_u32(dev->of_node, "arm,smc-id", &func_id);
 	if (ret < 0)
@@ -109,7 +112,8 @@ static int smc_send_message(struct scmi_chan_info *cinfo,
 
 	shmem_tx_prepare(scmi_info->shmem, xfer);
 
-	arm_smccc_1_1_invoke(scmi_info->func_id, 0, 0, 0, 0, 0, 0, 0, &res);
+	arm_smccc_1_1_invoke(scmi_info->func_id, scmi_info->shmem_paddr, 0, 0,
+			     0, 0, 0, 0, &res);
 	scmi_rx_callback(scmi_info->cinfo, shmem_read_header(scmi_info->shmem));
 
 	mutex_unlock(&scmi_info->shmem_lock);
-- 
2.26.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Florian Fainelli]

On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote:
> From: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
> 
> Currently, when SMC/HVC is used as transport, the base address of the
> shared memory used for communication is not passed to the SMCCC call.
> This means that such an address must be hard-coded into the bootloader.
> 
> In order to increase flexibility and allow the memory layout to be
> changed without modifying the bootloader, this patch adds the shared
> memory base address to the a1 argument of the SMCCC call.
> 
> On the Secure Monitor side, the service call implementation can
> therefore read the a1 argument in order to know the location of the
> shared memory to use. This change is backward compatible to existing
> service call implementations as long as they don't check for a1 to be
> zero.

resource_size_t being defined after phys_addr_t, its size is different
between 32-bit, 32-bit with PAE and 64-bit so it would probably make
more sense to define an physical address alignment, or maybe an address
that is in multiple of 4KBytes so you can address up to 36-bits of
physical address even on a 32-bit only system?

What discovery mechanism does the OS have that the specified address
within the SMCCC call has been accepted by the firmware given the return
value of that SMCCC call does not appear to be used or checked? Do we
just expect a timeout initializing the SCMI subsystem?

Given that the kernel must somehow reserve this memory as a shared
memory area for obvious reasons, and the trusted firmware must also
ensure it treats this memory region with specific permissions in its
translation regime, does it really make sense to give that much flexibility?

If your boot loader has FDT patching capability, maybe it can also do a
SMC call to provide the address to your trusted firmware, prior to
loading the Linux kernel, and then they both agree, prior to boot about
the shared memory address?

> 
> Signed-off-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
> Signed-off-by: Paul J. Murphy <paul.j.murphy@intel.com>
> ---
>  drivers/firmware/arm_scmi/smc.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/smc.c
> index 49bc4b0e8428..aef3a58f8266 100644
> --- a/drivers/firmware/arm_scmi/smc.c
> +++ b/drivers/firmware/arm_scmi/smc.c
> @@ -21,12 +21,14 @@
>   *
>   * @cinfo: SCMI channel info
>   * @shmem: Transmit/Receive shared memory area
> + * @shmem_paddr: Physical address of shmem
>   * @func_id: smc/hvc call function id
>   */
>  
>  struct scmi_smc {
>  	struct scmi_chan_info *cinfo;
>  	struct scmi_shared_mem __iomem *shmem;
> +	resource_size_t shmem_paddr;
>  	struct mutex shmem_lock;
>  	u32 func_id;
>  };
> @@ -73,6 +75,7 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo, struct device *dev,
>  		dev_err(dev, "failed to ioremap SCMI Tx shared memory\n");
>  		return -EADDRNOTAVAIL;
>  	}
> +	scmi_info->shmem_paddr = res.start;
>  
>  	ret = of_property_read_u32(dev->of_node, "arm,smc-id", &func_id);
>  	if (ret < 0)
> @@ -109,7 +112,8 @@ static int smc_send_message(struct scmi_chan_info *cinfo,
>  
>  	shmem_tx_prepare(scmi_info->shmem, xfer);
>  
> -	arm_smccc_1_1_invoke(scmi_info->func_id, 0, 0, 0, 0, 0, 0, 0, &res);
> +	arm_smccc_1_1_invoke(scmi_info->func_id, scmi_info->shmem_paddr, 0, 0,
> +			     0, 0, 0, 0, &res);
>  	scmi_rx_callback(scmi_info->cinfo, shmem_read_header(scmi_info->shmem));
>  
>  	mutex_unlock(&scmi_info->shmem_lock);
> 

-- 
Florian

Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Florian Fainelli]

On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote:
> From: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
> 
> Currently, when SMC/HVC is used as transport, the base address of the
> shared memory used for communication is not passed to the SMCCC call.
> This means that such an address must be hard-coded into the bootloader.
> 
> In order to increase flexibility and allow the memory layout to be
> changed without modifying the bootloader, this patch adds the shared
> memory base address to the a1 argument of the SMCCC call.
> 
> On the Secure Monitor side, the service call implementation can
> therefore read the a1 argument in order to know the location of the
> shared memory to use. This change is backward compatible to existing
> service call implementations as long as they don't check for a1 to be
> zero.

resource_size_t being defined after phys_addr_t, its size is different
between 32-bit, 32-bit with PAE and 64-bit so it would probably make
more sense to define an physical address alignment, or maybe an address
that is in multiple of 4KBytes so you can address up to 36-bits of
physical address even on a 32-bit only system?

What discovery mechanism does the OS have that the specified address
within the SMCCC call has been accepted by the firmware given the return
value of that SMCCC call does not appear to be used or checked? Do we
just expect a timeout initializing the SCMI subsystem?

Given that the kernel must somehow reserve this memory as a shared
memory area for obvious reasons, and the trusted firmware must also
ensure it treats this memory region with specific permissions in its
translation regime, does it really make sense to give that much flexibility?

If your boot loader has FDT patching capability, maybe it can also do a
SMC call to provide the address to your trusted firmware, prior to
loading the Linux kernel, and then they both agree, prior to boot about
the shared memory address?

> 
> Signed-off-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
> Signed-off-by: Paul J. Murphy <paul.j.murphy@intel.com>
> ---
>  drivers/firmware/arm_scmi/smc.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/smc.c
> index 49bc4b0e8428..aef3a58f8266 100644
> --- a/drivers/firmware/arm_scmi/smc.c
> +++ b/drivers/firmware/arm_scmi/smc.c
> @@ -21,12 +21,14 @@
>   *
>   * @cinfo: SCMI channel info
>   * @shmem: Transmit/Receive shared memory area
> + * @shmem_paddr: Physical address of shmem
>   * @func_id: smc/hvc call function id
>   */
>  
>  struct scmi_smc {
>  	struct scmi_chan_info *cinfo;
>  	struct scmi_shared_mem __iomem *shmem;
> +	resource_size_t shmem_paddr;
>  	struct mutex shmem_lock;
>  	u32 func_id;
>  };
> @@ -73,6 +75,7 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo, struct device *dev,
>  		dev_err(dev, "failed to ioremap SCMI Tx shared memory\n");
>  		return -EADDRNOTAVAIL;
>  	}
> +	scmi_info->shmem_paddr = res.start;
>  
>  	ret = of_property_read_u32(dev->of_node, "arm,smc-id", &func_id);
>  	if (ret < 0)
> @@ -109,7 +112,8 @@ static int smc_send_message(struct scmi_chan_info *cinfo,
>  
>  	shmem_tx_prepare(scmi_info->shmem, xfer);
>  
> -	arm_smccc_1_1_invoke(scmi_info->func_id, 0, 0, 0, 0, 0, 0, 0, &res);
> +	arm_smccc_1_1_invoke(scmi_info->func_id, scmi_info->shmem_paddr, 0, 0,
> +			     0, 0, 0, 0, &res);
>  	scmi_rx_callback(scmi_info->cinfo, shmem_read_header(scmi_info->shmem));
>  
>  	mutex_unlock(&scmi_info->shmem_lock);
> 

-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Daniele Alessandrelli]

Hi Florian,

Thanks for you feedback.

On Wed, 2020-07-15 at 15:43 -0700, Florian Fainelli wrote:
> 
> On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote:
> > From: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
> > 
> > Currently, when SMC/HVC is used as transport, the base address of
> > the
> > shared memory used for communication is not passed to the SMCCC
> > call.
> > This means that such an address must be hard-coded into the
> > bootloader.
> > 
> > In order to increase flexibility and allow the memory layout to be
> > changed without modifying the bootloader, this patch adds the
> > shared
> > memory base address to the a1 argument of the SMCCC call.
> > 
> > On the Secure Monitor side, the service call implementation can
> > therefore read the a1 argument in order to know the location of the
> > shared memory to use. This change is backward compatible to
> > existing
> > service call implementations as long as they don't check for a1 to
> > be
> > zero.
> 
> resource_size_t being defined after phys_addr_t, its size is
> different
> between 32-bit, 32-bit with PAE and 64-bit so it would probably make
> more sense to define an physical address alignment, or maybe an
> address
> that is in multiple of 4KBytes so you can address up to 36-bits of
> physical address even on a 32-bit only system?

I see your point. After a quick look, I think that, practically, the
issue is with ARM32 LPAE addresses, for which phys_addr_t is a u64. So,
basically, for AArch32 systems with LPAE the 64-bit shmem_paddr gets
truncated to 32-bit when it's passed to the SMC32/HVC32 call.

To solve that, I would prefer splitting the address between two SMC
parameters (a1 = addr_lo, a2 = addr_hi), instead of imposing an
arbitrary alignment. Would that be reasonable?

> 
> What discovery mechanism does the OS have that the specified address
> within the SMCCC call has been accepted by the firmware given the
> return
> value of that SMCCC call does not appear to be used or checked? Do we
> just expect a timeout initializing the SCMI subsystem?

The return code is actually checked at the end of the function:
https://elixir.bootlin.com/linux/v5.8-rc4/source/drivers/firmware/arm_scmi/smc.c#L118

But in the meantime scmi_rx_callback() has already been called. Not
sure if that's intentional or a possible bug.

> 
> Given that the kernel must somehow reserve this memory as a shared
> memory area for obvious reasons, and the trusted firmware must also
> ensure it treats this memory region with specific permissions in its
> translation regime, does it really make sense to give that much
> flexibility?

Well, the trusted firmware might reserve a bigger region to be used for
other service as well. In other words, the MMU of TF-A is not necessary
specifically set up for this region, but, possibly, for a bigger
general shared region.

Passing the SCMI shmem to the SMC call allows the shmem to be moved
within such bigger shared memory without modifying the trusted
firmware.

> 
> If your boot loader has FDT patching capability, maybe it can also do
> a
> SMC call to provide the address to your trusted firmware, prior to
> loading the Linux kernel, and then they both agree, prior to boot
> about
> the shared memory address?

Yes, that's a possible solution, but it looks more complicated to me,
since it adds an additional component (the boot loader) to the
equation, while the goal of this patch was to reduce the coupling
between components (namely the DT/kernel and the trusted firmware).

I guess my question is: if we fix the handling of LPAE addresses and
the SMC return code, what is the drawback of having the shmem address
passed to the SMC?

Anyway, I should have mentioned this in the commit message (sorry for
not doing so), but I submitted this patch because initial feedback from
Sudeep was positive [1]; but if there is no consensus around it I'm
fine with dropping it.

[1] https://lore.kernel.org/lkml/20200710075931.GB1189@bogus/

> 
> > Signed-off-by: Daniele Alessandrelli <
> > daniele.alessandrelli@intel.com>
> > Signed-off-by: Paul J. Murphy <paul.j.murphy@intel.com>
> > ---
> >  drivers/firmware/arm_scmi/smc.c | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/firmware/arm_scmi/smc.c
> > b/drivers/firmware/arm_scmi/smc.c
> > index 49bc4b0e8428..aef3a58f8266 100644
> > --- a/drivers/firmware/arm_scmi/smc.c
> > +++ b/drivers/firmware/arm_scmi/smc.c
> > @@ -21,12 +21,14 @@
> >   *
> >   * @cinfo: SCMI channel info
> >   * @shmem: Transmit/Receive shared memory area
> > + * @shmem_paddr: Physical address of shmem
> >   * @func_id: smc/hvc call function id
> >   */
> >  
> >  struct scmi_smc {
> >  	struct scmi_chan_info *cinfo;
> >  	struct scmi_shared_mem __iomem *shmem;
> > +	resource_size_t shmem_paddr;
> >  	struct mutex shmem_lock;
> >  	u32 func_id;
> >  };
> > @@ -73,6 +75,7 @@ static int smc_chan_setup(struct scmi_chan_info
> > *cinfo, struct device *dev,
> >  		dev_err(dev, "failed to ioremap SCMI Tx shared
> > memory\n");
> >  		return -EADDRNOTAVAIL;
> >  	}
> > +	scmi_info->shmem_paddr = res.start;
> >  
> >  	ret = of_property_read_u32(dev->of_node, "arm,smc-id",
> > &func_id);
> >  	if (ret < 0)
> > @@ -109,7 +112,8 @@ static int smc_send_message(struct
> > scmi_chan_info *cinfo,
> >  
> >  	shmem_tx_prepare(scmi_info->shmem, xfer);
> >  
> > -	arm_smccc_1_1_invoke(scmi_info->func_id, 0, 0, 0, 0, 0, 0, 0,
> > &res);
> > +	arm_smccc_1_1_invoke(scmi_info->func_id, scmi_info-
> > >shmem_paddr, 0, 0,
> > +			     0, 0, 0, 0, &res);
> >  	scmi_rx_callback(scmi_info->cinfo, shmem_read_header(scmi_info-
> > >shmem));
> >  
> >  	mutex_unlock(&scmi_info->shmem_lock);
> > 

Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Daniele Alessandrelli]

Hi Florian,

Thanks for you feedback.

On Wed, 2020-07-15 at 15:43 -0700, Florian Fainelli wrote:
> 
> On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote:
> > From: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
> > 
> > Currently, when SMC/HVC is used as transport, the base address of
> > the
> > shared memory used for communication is not passed to the SMCCC
> > call.
> > This means that such an address must be hard-coded into the
> > bootloader.
> > 
> > In order to increase flexibility and allow the memory layout to be
> > changed without modifying the bootloader, this patch adds the
> > shared
> > memory base address to the a1 argument of the SMCCC call.
> > 
> > On the Secure Monitor side, the service call implementation can
> > therefore read the a1 argument in order to know the location of the
> > shared memory to use. This change is backward compatible to
> > existing
> > service call implementations as long as they don't check for a1 to
> > be
> > zero.
> 
> resource_size_t being defined after phys_addr_t, its size is
> different
> between 32-bit, 32-bit with PAE and 64-bit so it would probably make
> more sense to define an physical address alignment, or maybe an
> address
> that is in multiple of 4KBytes so you can address up to 36-bits of
> physical address even on a 32-bit only system?

I see your point. After a quick look, I think that, practically, the
issue is with ARM32 LPAE addresses, for which phys_addr_t is a u64. So,
basically, for AArch32 systems with LPAE the 64-bit shmem_paddr gets
truncated to 32-bit when it's passed to the SMC32/HVC32 call.

To solve that, I would prefer splitting the address between two SMC
parameters (a1 = addr_lo, a2 = addr_hi), instead of imposing an
arbitrary alignment. Would that be reasonable?

> 
> What discovery mechanism does the OS have that the specified address
> within the SMCCC call has been accepted by the firmware given the
> return
> value of that SMCCC call does not appear to be used or checked? Do we
> just expect a timeout initializing the SCMI subsystem?

The return code is actually checked at the end of the function:
https://elixir.bootlin.com/linux/v5.8-rc4/source/drivers/firmware/arm_scmi/smc.c#L118

But in the meantime scmi_rx_callback() has already been called. Not
sure if that's intentional or a possible bug.

> 
> Given that the kernel must somehow reserve this memory as a shared
> memory area for obvious reasons, and the trusted firmware must also
> ensure it treats this memory region with specific permissions in its
> translation regime, does it really make sense to give that much
> flexibility?

Well, the trusted firmware might reserve a bigger region to be used for
other service as well. In other words, the MMU of TF-A is not necessary
specifically set up for this region, but, possibly, for a bigger
general shared region.

Passing the SCMI shmem to the SMC call allows the shmem to be moved
within such bigger shared memory without modifying the trusted
firmware.

> 
> If your boot loader has FDT patching capability, maybe it can also do
> a
> SMC call to provide the address to your trusted firmware, prior to
> loading the Linux kernel, and then they both agree, prior to boot
> about
> the shared memory address?

Yes, that's a possible solution, but it looks more complicated to me,
since it adds an additional component (the boot loader) to the
equation, while the goal of this patch was to reduce the coupling
between components (namely the DT/kernel and the trusted firmware).

I guess my question is: if we fix the handling of LPAE addresses and
the SMC return code, what is the drawback of having the shmem address
passed to the SMC?

Anyway, I should have mentioned this in the commit message (sorry for
not doing so), but I submitted this patch because initial feedback from
Sudeep was positive [1]; but if there is no consensus around it I'm
fine with dropping it.

[1] https://lore.kernel.org/lkml/20200710075931.GB1189@bogus/

> 
> > Signed-off-by: Daniele Alessandrelli <
> > daniele.alessandrelli@intel.com>
> > Signed-off-by: Paul J. Murphy <paul.j.murphy@intel.com>
> > ---
> >  drivers/firmware/arm_scmi/smc.c | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/firmware/arm_scmi/smc.c
> > b/drivers/firmware/arm_scmi/smc.c
> > index 49bc4b0e8428..aef3a58f8266 100644
> > --- a/drivers/firmware/arm_scmi/smc.c
> > +++ b/drivers/firmware/arm_scmi/smc.c
> > @@ -21,12 +21,14 @@
> >   *
> >   * @cinfo: SCMI channel info
> >   * @shmem: Transmit/Receive shared memory area
> > + * @shmem_paddr: Physical address of shmem
> >   * @func_id: smc/hvc call function id
> >   */
> >  
> >  struct scmi_smc {
> >  	struct scmi_chan_info *cinfo;
> >  	struct scmi_shared_mem __iomem *shmem;
> > +	resource_size_t shmem_paddr;
> >  	struct mutex shmem_lock;
> >  	u32 func_id;
> >  };
> > @@ -73,6 +75,7 @@ static int smc_chan_setup(struct scmi_chan_info
> > *cinfo, struct device *dev,
> >  		dev_err(dev, "failed to ioremap SCMI Tx shared
> > memory\n");
> >  		return -EADDRNOTAVAIL;
> >  	}
> > +	scmi_info->shmem_paddr = res.start;
> >  
> >  	ret = of_property_read_u32(dev->of_node, "arm,smc-id",
> > &func_id);
> >  	if (ret < 0)
> > @@ -109,7 +112,8 @@ static int smc_send_message(struct
> > scmi_chan_info *cinfo,
> >  
> >  	shmem_tx_prepare(scmi_info->shmem, xfer);
> >  
> > -	arm_smccc_1_1_invoke(scmi_info->func_id, 0, 0, 0, 0, 0, 0, 0,
> > &res);
> > +	arm_smccc_1_1_invoke(scmi_info->func_id, scmi_info-
> > >shmem_paddr, 0, 0,
> > +			     0, 0, 0, 0, &res);
> >  	scmi_rx_callback(scmi_info->cinfo, shmem_read_header(scmi_info-
> > >shmem));
> >  
> >  	mutex_unlock(&scmi_info->shmem_lock);
> > 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Florian Fainelli]

On 7/16/2020 7:13 AM, Daniele Alessandrelli wrote:
> Hi Florian,
> 
> Thanks for you feedback.
> 
> On Wed, 2020-07-15 at 15:43 -0700, Florian Fainelli wrote:
>>
>> On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote:
>>> From: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
>>>
>>> Currently, when SMC/HVC is used as transport, the base address of
>>> the
>>> shared memory used for communication is not passed to the SMCCC
>>> call.
>>> This means that such an address must be hard-coded into the
>>> bootloader.
>>>
>>> In order to increase flexibility and allow the memory layout to be
>>> changed without modifying the bootloader, this patch adds the
>>> shared
>>> memory base address to the a1 argument of the SMCCC call.
>>>
>>> On the Secure Monitor side, the service call implementation can
>>> therefore read the a1 argument in order to know the location of the
>>> shared memory to use. This change is backward compatible to
>>> existing
>>> service call implementations as long as they don't check for a1 to
>>> be
>>> zero.
>>
>> resource_size_t being defined after phys_addr_t, its size is
>> different
>> between 32-bit, 32-bit with PAE and 64-bit so it would probably make
>> more sense to define an physical address alignment, or maybe an
>> address
>> that is in multiple of 4KBytes so you can address up to 36-bits of
>> physical address even on a 32-bit only system?
> 
> I see your point. After a quick look, I think that, practically, the
> issue is with ARM32 LPAE addresses, for which phys_addr_t is a u64. So,
> basically, for AArch32 systems with LPAE the 64-bit shmem_paddr gets
> truncated to 32-bit when it's passed to the SMC32/HVC32 call.
> 
> To solve that, I would prefer splitting the address between two SMC
> parameters (a1 = addr_lo, a2 = addr_hi), instead of imposing an
> arbitrary alignment. Would that be reasonable?

The low/high part would only be relevant on a 32-bit LPAE platform which
is probably a corner case, I would just pass the shmem_paddr / 4096
since that is the smallest granule size and alignment possible and it
still allows you to map up to 36-bits of physical address, which is the
maximum that the long descriptor in LPAE can support. For 64-bit we have
no such problems since we have the full register width.

> 
>>
>> What discovery mechanism does the OS have that the specified address
>> within the SMCCC call has been accepted by the firmware given the
>> return
>> value of that SMCCC call does not appear to be used or checked? Do we
>> just expect a timeout initializing the SCMI subsystem?
> 
> The return code is actually checked at the end of the function:
> https://elixir.bootlin.com/linux/v5.8-rc4/source/drivers/firmware/arm_scmi/smc.c#L118
> 
> But in the meantime scmi_rx_callback() has already been called. Not
> sure if that's intentional or a possible bug.
> 
>>
>> Given that the kernel must somehow reserve this memory as a shared
>> memory area for obvious reasons, and the trusted firmware must also
>> ensure it treats this memory region with specific permissions in its
>> translation regime, does it really make sense to give that much
>> flexibility?
> 
> Well, the trusted firmware might reserve a bigger region to be used for
> other service as well. In other words, the MMU of TF-A is not necessary
> specifically set up for this region, but, possibly, for a bigger
> general shared region.

But presumably the Linux shared memory area should be mapped in a
slightly different way than

> 
> Passing the SCMI shmem to the SMC call allows the shmem to be moved
> within such bigger shared memory without modifying the trusted
> firmware.
> 
>>
>> If your boot loader has FDT patching capability, maybe it can also do
>> a
>> SMC call to provide the address to your trusted firmware, prior to
>> loading the Linux kernel, and then they both agree, prior to boot
>> about
>> the shared memory address?
> 
> Yes, that's a possible solution, but it looks more complicated to me,
> since it adds an additional component (the boot loader) to the
> equation, while the goal of this patch was to reduce the coupling
> between components (namely the DT/kernel and the trusted firmware).
> 
> I guess my question is: if we fix the handling of LPAE addresses and
> the SMC return code, what is the drawback of having the shmem address
> passed to the SMC?

My only concern is that if somehow Linux gets assigned a shared memory
range that is completely outside of what the trusted firmware has
already mapped, or is capable of addressing, or any combination thereof,
it could be challenging to debug what is going on, especially if INVALID
PARAMETER must not be returned (assuming this is to avoid Linux
discovering where other shared memory areas pertaining to the firmware
reside?).

The other concern I have is that we are not documenting the various
SMCCC calling conventions, soon enough it will be come out of control,
and we are already allowing people to define their own function IDs and
parameters to call into the trusted firmware. This sounds like something
that is so basic that it should be standardized from the top, by ARM.

> 
> Anyway, I should have mentioned this in the commit message (sorry for
> not doing so), but I submitted this patch because initial feedback from
> Sudeep was positive [1]; but if there is no consensus around it I'm
> fine with dropping it.
> 
> [1] https://lore.kernel.org/lkml/20200710075931.GB1189@bogus/

My review is by no means authoritative however in deploying SCMI on our
Broadcom STB platforms some experience was gained in the process which
is how it piqued my interest. Thanks for providing more background to
this patch, this does help.

We have opted for a solution where the boot loader knows about all
possible reserved regions prior to booting/loading the trusted firmware
as well as the kernel, therefore it can pass that information to both
and we never really had a situation where the two need to evolve in an
uncoordinated way.
-- 
Florian

Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Florian Fainelli]

On 7/16/2020 7:13 AM, Daniele Alessandrelli wrote:
> Hi Florian,
> 
> Thanks for you feedback.
> 
> On Wed, 2020-07-15 at 15:43 -0700, Florian Fainelli wrote:
>>
>> On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote:
>>> From: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
>>>
>>> Currently, when SMC/HVC is used as transport, the base address of
>>> the
>>> shared memory used for communication is not passed to the SMCCC
>>> call.
>>> This means that such an address must be hard-coded into the
>>> bootloader.
>>>
>>> In order to increase flexibility and allow the memory layout to be
>>> changed without modifying the bootloader, this patch adds the
>>> shared
>>> memory base address to the a1 argument of the SMCCC call.
>>>
>>> On the Secure Monitor side, the service call implementation can
>>> therefore read the a1 argument in order to know the location of the
>>> shared memory to use. This change is backward compatible to
>>> existing
>>> service call implementations as long as they don't check for a1 to
>>> be
>>> zero.
>>
>> resource_size_t being defined after phys_addr_t, its size is
>> different
>> between 32-bit, 32-bit with PAE and 64-bit so it would probably make
>> more sense to define an physical address alignment, or maybe an
>> address
>> that is in multiple of 4KBytes so you can address up to 36-bits of
>> physical address even on a 32-bit only system?
> 
> I see your point. After a quick look, I think that, practically, the
> issue is with ARM32 LPAE addresses, for which phys_addr_t is a u64. So,
> basically, for AArch32 systems with LPAE the 64-bit shmem_paddr gets
> truncated to 32-bit when it's passed to the SMC32/HVC32 call.
> 
> To solve that, I would prefer splitting the address between two SMC
> parameters (a1 = addr_lo, a2 = addr_hi), instead of imposing an
> arbitrary alignment. Would that be reasonable?

The low/high part would only be relevant on a 32-bit LPAE platform which
is probably a corner case, I would just pass the shmem_paddr / 4096
since that is the smallest granule size and alignment possible and it
still allows you to map up to 36-bits of physical address, which is the
maximum that the long descriptor in LPAE can support. For 64-bit we have
no such problems since we have the full register width.

> 
>>
>> What discovery mechanism does the OS have that the specified address
>> within the SMCCC call has been accepted by the firmware given the
>> return
>> value of that SMCCC call does not appear to be used or checked? Do we
>> just expect a timeout initializing the SCMI subsystem?
> 
> The return code is actually checked at the end of the function:
> https://elixir.bootlin.com/linux/v5.8-rc4/source/drivers/firmware/arm_scmi/smc.c#L118
> 
> But in the meantime scmi_rx_callback() has already been called. Not
> sure if that's intentional or a possible bug.
> 
>>
>> Given that the kernel must somehow reserve this memory as a shared
>> memory area for obvious reasons, and the trusted firmware must also
>> ensure it treats this memory region with specific permissions in its
>> translation regime, does it really make sense to give that much
>> flexibility?
> 
> Well, the trusted firmware might reserve a bigger region to be used for
> other service as well. In other words, the MMU of TF-A is not necessary
> specifically set up for this region, but, possibly, for a bigger
> general shared region.

But presumably the Linux shared memory area should be mapped in a
slightly different way than

> 
> Passing the SCMI shmem to the SMC call allows the shmem to be moved
> within such bigger shared memory without modifying the trusted
> firmware.
> 
>>
>> If your boot loader has FDT patching capability, maybe it can also do
>> a
>> SMC call to provide the address to your trusted firmware, prior to
>> loading the Linux kernel, and then they both agree, prior to boot
>> about
>> the shared memory address?
> 
> Yes, that's a possible solution, but it looks more complicated to me,
> since it adds an additional component (the boot loader) to the
> equation, while the goal of this patch was to reduce the coupling
> between components (namely the DT/kernel and the trusted firmware).
> 
> I guess my question is: if we fix the handling of LPAE addresses and
> the SMC return code, what is the drawback of having the shmem address
> passed to the SMC?

My only concern is that if somehow Linux gets assigned a shared memory
range that is completely outside of what the trusted firmware has
already mapped, or is capable of addressing, or any combination thereof,
it could be challenging to debug what is going on, especially if INVALID
PARAMETER must not be returned (assuming this is to avoid Linux
discovering where other shared memory areas pertaining to the firmware
reside?).

The other concern I have is that we are not documenting the various
SMCCC calling conventions, soon enough it will be come out of control,
and we are already allowing people to define their own function IDs and
parameters to call into the trusted firmware. This sounds like something
that is so basic that it should be standardized from the top, by ARM.

> 
> Anyway, I should have mentioned this in the commit message (sorry for
> not doing so), but I submitted this patch because initial feedback from
> Sudeep was positive [1]; but if there is no consensus around it I'm
> fine with dropping it.
> 
> [1] https://lore.kernel.org/lkml/20200710075931.GB1189@bogus/

My review is by no means authoritative however in deploying SCMI on our
Broadcom STB platforms some experience was gained in the process which
is how it piqued my interest. Thanks for providing more background to
this patch, this does help.

We have opted for a solution where the boot loader knows about all
possible reserved regions prior to booting/loading the trusted firmware
as well as the kernel, therefore it can pass that information to both
and we never really had a situation where the two need to evolve in an
uncoordinated way.
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Sudeep Holla]

On Wed, Jul 15, 2020 at 03:43:24PM -0700, Florian Fainelli wrote:
>
>
> On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote:
> > From: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
> >
> > Currently, when SMC/HVC is used as transport, the base address of the
> > shared memory used for communication is not passed to the SMCCC call.
> > This means that such an address must be hard-coded into the bootloader.
> >
> > In order to increase flexibility and allow the memory layout to be
> > changed without modifying the bootloader, this patch adds the shared
> > memory base address to the a1 argument of the SMCCC call.
> >
> > On the Secure Monitor side, the service call implementation can
> > therefore read the a1 argument in order to know the location of the
> > shared memory to use. This change is backward compatible to existing
> > service call implementations as long as they don't check for a1 to be
> > zero.
>
> resource_size_t being defined after phys_addr_t, its size is different
> between 32-bit, 32-bit with PAE and 64-bit so it would probably make
> more sense to define an physical address alignment, or maybe an address
> that is in multiple of 4KBytes so you can address up to 36-bits of
> physical address even on a 32-bit only system?
>

Good point, I had forgotten about LPAE. Thanks for pointing it out.

> What discovery mechanism does the OS have that the specified address
> within the SMCCC call has been accepted by the firmware given the return
> value of that SMCCC call does not appear to be used or checked? Do we
> just expect a timeout initializing the SCMI subsystem?
>

Agreed, we need to add the check for proper return value then and
definitely document it very clearly as we are trying to standardise
a call to vendor SiP FID space of SMCCC.

> Given that the kernel must somehow reserve this memory as a shared
> memory area for obvious reasons, and the trusted firmware must also
> ensure it treats this memory region with specific permissions in its
> translation regime, does it really make sense to give that much flexibility?
>

I expect so and this comes as shmem property from DT already. We are
just passing the value obtained from there as is. This is just to help
TFA or the firmware to identify the specific channel/shmem as SMC/HVC
otherwise has no way to do so.

> If your boot loader has FDT patching capability, maybe it can also do a
> SMC call to provide the address to your trusted firmware, prior to
> loading the Linux kernel, and then they both agree, prior to boot about
> the shared memory address?
>

Yes, but we definitely can't rely on such mechanism in the kernel. It is
more a platform choice as they run different bootloaders.

--
Regards,
Sudeep

Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Sudeep Holla]

On Wed, Jul 15, 2020 at 03:43:24PM -0700, Florian Fainelli wrote:
>
>
> On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote:
> > From: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
> >
> > Currently, when SMC/HVC is used as transport, the base address of the
> > shared memory used for communication is not passed to the SMCCC call.
> > This means that such an address must be hard-coded into the bootloader.
> >
> > In order to increase flexibility and allow the memory layout to be
> > changed without modifying the bootloader, this patch adds the shared
> > memory base address to the a1 argument of the SMCCC call.
> >
> > On the Secure Monitor side, the service call implementation can
> > therefore read the a1 argument in order to know the location of the
> > shared memory to use. This change is backward compatible to existing
> > service call implementations as long as they don't check for a1 to be
> > zero.
>
> resource_size_t being defined after phys_addr_t, its size is different
> between 32-bit, 32-bit with PAE and 64-bit so it would probably make
> more sense to define an physical address alignment, or maybe an address
> that is in multiple of 4KBytes so you can address up to 36-bits of
> physical address even on a 32-bit only system?
>

Good point, I had forgotten about LPAE. Thanks for pointing it out.

> What discovery mechanism does the OS have that the specified address
> within the SMCCC call has been accepted by the firmware given the return
> value of that SMCCC call does not appear to be used or checked? Do we
> just expect a timeout initializing the SCMI subsystem?
>

Agreed, we need to add the check for proper return value then and
definitely document it very clearly as we are trying to standardise
a call to vendor SiP FID space of SMCCC.

> Given that the kernel must somehow reserve this memory as a shared
> memory area for obvious reasons, and the trusted firmware must also
> ensure it treats this memory region with specific permissions in its
> translation regime, does it really make sense to give that much flexibility?
>

I expect so and this comes as shmem property from DT already. We are
just passing the value obtained from there as is. This is just to help
TFA or the firmware to identify the specific channel/shmem as SMC/HVC
otherwise has no way to do so.

> If your boot loader has FDT patching capability, maybe it can also do a
> SMC call to provide the address to your trusted firmware, prior to
> loading the Linux kernel, and then they both agree, prior to boot about
> the shared memory address?
>

Yes, but we definitely can't rely on such mechanism in the kernel. It is
more a platform choice as they run different bootloaders.

--
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Sudeep Holla]

On Thu, Jul 16, 2020 at 03:13:03PM +0100, Daniele Alessandrelli wrote:
> Hi Florian,
>
> Thanks for you feedback.
>
> On Wed, 2020-07-15 at 15:43 -0700, Florian Fainelli wrote:
> >
> > On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote:
> > > From: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
> > >
> > > Currently, when SMC/HVC is used as transport, the base address of
> > > the
> > > shared memory used for communication is not passed to the SMCCC
> > > call.
> > > This means that such an address must be hard-coded into the
> > > bootloader.
> > >
> > > In order to increase flexibility and allow the memory layout to be
> > > changed without modifying the bootloader, this patch adds the
> > > shared
> > > memory base address to the a1 argument of the SMCCC call.
> > >
> > > On the Secure Monitor side, the service call implementation can
> > > therefore read the a1 argument in order to know the location of the
> > > shared memory to use. This change is backward compatible to
> > > existing
> > > service call implementations as long as they don't check for a1 to
> > > be
> > > zero.
> >
> > resource_size_t being defined after phys_addr_t, its size is
> > different
> > between 32-bit, 32-bit with PAE and 64-bit so it would probably make
> > more sense to define an physical address alignment, or maybe an
> > address
> > that is in multiple of 4KBytes so you can address up to 36-bits of
> > physical address even on a 32-bit only system?
>
> I see your point. After a quick look, I think that, practically, the
> issue is with ARM32 LPAE addresses, for which phys_addr_t is a u64. So,
> basically, for AArch32 systems with LPAE the 64-bit shmem_paddr gets
> truncated to 32-bit when it's passed to the SMC32/HVC32 call.
>
> To solve that, I would prefer splitting the address between two SMC
> parameters (a1 = addr_lo, a2 = addr_hi), instead of imposing an
> arbitrary alignment. Would that be reasonable?
>

Again beware of the fact that this is vendor SiP FID space of SMCCC.
Standardising that informally inside the Linux kernel is already bit
risky and challenging. I don't want to complicate it with above
splitting of address way.

> >
> > What discovery mechanism does the OS have that the specified address
> > within the SMCCC call has been accepted by the firmware given the
> > return
> > value of that SMCCC call does not appear to be used or checked? Do we
> > just expect a timeout initializing the SCMI subsystem?
>
> The return code is actually checked at the end of the function:
> https://elixir.bootlin.com/linux/v5.8-rc4/source/drivers/firmware/arm_scmi/smc.c#L118
>
> But in the meantime scmi_rx_callback() has already been called. Not
> sure if that's intentional or a possible bug.
>

Yes, thanks for the catch. Not sure if it was intentional, Peng ?
Even if it was I would like to fix as it is unnecessary to read response
from shmem which may have garbage or the input itself when the command
returns error.

> >
> > Given that the kernel must somehow reserve this memory as a shared
> > memory area for obvious reasons, and the trusted firmware must also
> > ensure it treats this memory region with specific permissions in its
> > translation regime, does it really make sense to give that much
> > flexibility?
>
> Well, the trusted firmware might reserve a bigger region to be used for
> other service as well. In other words, the MMU of TF-A is not necessary
> specifically set up for this region, but, possibly, for a bigger
> general shared region.
>
> Passing the SCMI shmem to the SMC call allows the shmem to be moved
> within such bigger shared memory without modifying the trusted
> firmware.
>

I am not entirely sure about this. I see this base address here as a
unique identifier referred in the SCMI specification(5.1.3.1 Doorbell):

"If the doorbell is SMC or HVC based, it should follow the SMC Calling
Convention [SMCCC]. The doorbell needs to provide the identifier of
the Shared Memory area that contains the payload. The Shared Memory area
containing the payload is updated with the SCMI return response when the
call returns. The identifier of the Shared Memory area should be 32-bits
and each identifier should map to a distinct Shared Memory area."

Sorry I seem to have missed the 32-bit part here when I said yes for
using address as the identifier. I wasn't explicit before when I said
I was OK for the address as 2nd parameter.

Now I recall that I was thinking about additional/optional property from
DT for this identifier, absence of which will be passing 0 as the id.

> >
> > If your boot loader has FDT patching capability, maybe it can also do
> > a
> > SMC call to provide the address to your trusted firmware, prior to
> > loading the Linux kernel, and then they both agree, prior to boot
> > about
> > the shared memory address?
>
> Yes, that's a possible solution, but it looks more complicated to me,
> since it adds an additional component (the boot loader) to the
> equation, while the goal of this patch was to reduce the coupling
> between components (namely the DT/kernel and the trusted firmware).
>

I agree with you too along with Florian's idea but I don't want to
rely on that in the kernel.

> I guess my question is: if we fix the handling of LPAE addresses and
> the SMC return code, what is the drawback of having the shmem address
> passed to the SMC?
>

My main worry is the 32-bit identifier as specified in the spec now. I
had missed that aspect in the spec when I agreed to use the address.

> Anyway, I should have mentioned this in the commit message (sorry for
> not doing so), but I submitted this patch because initial feedback from
> Sudeep was positive [1]; but if there is no consensus around it I'm
> fine with dropping it.
>
> [1] https://lore.kernel.org/lkml/20200710075931.GB1189@bogus/
>

Yes I am fine with the idea of adding identifier for distinguishing the
shmem if there are multiple channels. I haven't brought the idea of
changing that address w/o modifying TFA/firmware as IMO it is not that
simple. Florian has covered the reasons for the same already.

--
Regards,
Sudeep

Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Sudeep Holla]

On Thu, Jul 16, 2020 at 03:13:03PM +0100, Daniele Alessandrelli wrote:
> Hi Florian,
>
> Thanks for you feedback.
>
> On Wed, 2020-07-15 at 15:43 -0700, Florian Fainelli wrote:
> >
> > On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote:
> > > From: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
> > >
> > > Currently, when SMC/HVC is used as transport, the base address of
> > > the
> > > shared memory used for communication is not passed to the SMCCC
> > > call.
> > > This means that such an address must be hard-coded into the
> > > bootloader.
> > >
> > > In order to increase flexibility and allow the memory layout to be
> > > changed without modifying the bootloader, this patch adds the
> > > shared
> > > memory base address to the a1 argument of the SMCCC call.
> > >
> > > On the Secure Monitor side, the service call implementation can
> > > therefore read the a1 argument in order to know the location of the
> > > shared memory to use. This change is backward compatible to
> > > existing
> > > service call implementations as long as they don't check for a1 to
> > > be
> > > zero.
> >
> > resource_size_t being defined after phys_addr_t, its size is
> > different
> > between 32-bit, 32-bit with PAE and 64-bit so it would probably make
> > more sense to define an physical address alignment, or maybe an
> > address
> > that is in multiple of 4KBytes so you can address up to 36-bits of
> > physical address even on a 32-bit only system?
>
> I see your point. After a quick look, I think that, practically, the
> issue is with ARM32 LPAE addresses, for which phys_addr_t is a u64. So,
> basically, for AArch32 systems with LPAE the 64-bit shmem_paddr gets
> truncated to 32-bit when it's passed to the SMC32/HVC32 call.
>
> To solve that, I would prefer splitting the address between two SMC
> parameters (a1 = addr_lo, a2 = addr_hi), instead of imposing an
> arbitrary alignment. Would that be reasonable?
>

Again beware of the fact that this is vendor SiP FID space of SMCCC.
Standardising that informally inside the Linux kernel is already bit
risky and challenging. I don't want to complicate it with above
splitting of address way.

> >
> > What discovery mechanism does the OS have that the specified address
> > within the SMCCC call has been accepted by the firmware given the
> > return
> > value of that SMCCC call does not appear to be used or checked? Do we
> > just expect a timeout initializing the SCMI subsystem?
>
> The return code is actually checked at the end of the function:
> https://elixir.bootlin.com/linux/v5.8-rc4/source/drivers/firmware/arm_scmi/smc.c#L118
>
> But in the meantime scmi_rx_callback() has already been called. Not
> sure if that's intentional or a possible bug.
>

Yes, thanks for the catch. Not sure if it was intentional, Peng ?
Even if it was I would like to fix as it is unnecessary to read response
from shmem which may have garbage or the input itself when the command
returns error.

> >
> > Given that the kernel must somehow reserve this memory as a shared
> > memory area for obvious reasons, and the trusted firmware must also
> > ensure it treats this memory region with specific permissions in its
> > translation regime, does it really make sense to give that much
> > flexibility?
>
> Well, the trusted firmware might reserve a bigger region to be used for
> other service as well. In other words, the MMU of TF-A is not necessary
> specifically set up for this region, but, possibly, for a bigger
> general shared region.
>
> Passing the SCMI shmem to the SMC call allows the shmem to be moved
> within such bigger shared memory without modifying the trusted
> firmware.
>

I am not entirely sure about this. I see this base address here as a
unique identifier referred in the SCMI specification(5.1.3.1 Doorbell):

"If the doorbell is SMC or HVC based, it should follow the SMC Calling
Convention [SMCCC]. The doorbell needs to provide the identifier of
the Shared Memory area that contains the payload. The Shared Memory area
containing the payload is updated with the SCMI return response when the
call returns. The identifier of the Shared Memory area should be 32-bits
and each identifier should map to a distinct Shared Memory area."

Sorry I seem to have missed the 32-bit part here when I said yes for
using address as the identifier. I wasn't explicit before when I said
I was OK for the address as 2nd parameter.

Now I recall that I was thinking about additional/optional property from
DT for this identifier, absence of which will be passing 0 as the id.

> >
> > If your boot loader has FDT patching capability, maybe it can also do
> > a
> > SMC call to provide the address to your trusted firmware, prior to
> > loading the Linux kernel, and then they both agree, prior to boot
> > about
> > the shared memory address?
>
> Yes, that's a possible solution, but it looks more complicated to me,
> since it adds an additional component (the boot loader) to the
> equation, while the goal of this patch was to reduce the coupling
> between components (namely the DT/kernel and the trusted firmware).
>

I agree with you too along with Florian's idea but I don't want to
rely on that in the kernel.

> I guess my question is: if we fix the handling of LPAE addresses and
> the SMC return code, what is the drawback of having the shmem address
> passed to the SMC?
>

My main worry is the 32-bit identifier as specified in the spec now. I
had missed that aspect in the spec when I agreed to use the address.

> Anyway, I should have mentioned this in the commit message (sorry for
> not doing so), but I submitted this patch because initial feedback from
> Sudeep was positive [1]; but if there is no consensus around it I'm
> fine with dropping it.
>
> [1] https://lore.kernel.org/lkml/20200710075931.GB1189@bogus/
>

Yes I am fine with the idea of adding identifier for distinguishing the
shmem if there are multiple channels. I haven't brought the idea of
changing that address w/o modifying TFA/firmware as IMO it is not that
simple. Florian has covered the reasons for the same already.

--
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Sudeep Holla]

On Thu, Jul 16, 2020 at 12:57:23PM -0700, Florian Fainelli wrote:
>
>
> On 7/16/2020 7:13 AM, Daniele Alessandrelli wrote:
> > Hi Florian,
> >
> > Thanks for you feedback.
> >
> > On Wed, 2020-07-15 at 15:43 -0700, Florian Fainelli wrote:
> >>
> >> On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote:
> >>> From: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
> >>>
> >>> Currently, when SMC/HVC is used as transport, the base address of
> >>> the
> >>> shared memory used for communication is not passed to the SMCCC
> >>> call.
> >>> This means that such an address must be hard-coded into the
> >>> bootloader.
> >>>
> >>> In order to increase flexibility and allow the memory layout to be
> >>> changed without modifying the bootloader, this patch adds the
> >>> shared
> >>> memory base address to the a1 argument of the SMCCC call.
> >>>
> >>> On the Secure Monitor side, the service call implementation can
> >>> therefore read the a1 argument in order to know the location of the
> >>> shared memory to use. This change is backward compatible to
> >>> existing
> >>> service call implementations as long as they don't check for a1 to
> >>> be
> >>> zero.
> >>
> >> resource_size_t being defined after phys_addr_t, its size is
> >> different
> >> between 32-bit, 32-bit with PAE and 64-bit so it would probably make
> >> more sense to define an physical address alignment, or maybe an
> >> address
> >> that is in multiple of 4KBytes so you can address up to 36-bits of
> >> physical address even on a 32-bit only system?
> >
> > I see your point. After a quick look, I think that, practically, the
> > issue is with ARM32 LPAE addresses, for which phys_addr_t is a u64. So,
> > basically, for AArch32 systems with LPAE the 64-bit shmem_paddr gets
> > truncated to 32-bit when it's passed to the SMC32/HVC32 call.
> >
> > To solve that, I would prefer splitting the address between two SMC
> > parameters (a1 = addr_lo, a2 = addr_hi), instead of imposing an
> > arbitrary alignment. Would that be reasonable?
>
> The low/high part would only be relevant on a 32-bit LPAE platform which
> is probably a corner case, I would just pass the shmem_paddr / 4096
> since that is the smallest granule size and alignment possible and it
> still allows you to map up to 36-bits of physical address, which is the
> maximum that the long descriptor in LPAE can support. For 64-bit we have
> no such problems since we have the full register width.
>

OK, I will check if 32-bit identifier can be relaxed in the spec in which
case we can avoid having DT binding for the identifier. If that is possible
we could use addr/4k page size.

> >>
> >> What discovery mechanism does the OS have that the specified address
> >> within the SMCCC call has been accepted by the firmware given the
> >> return value of that SMCCC call does not appear to be used or checked? Do
> >> we just expect a timeout initializing the SCMI subsystem?
> >
> > The return code is actually checked at the end of the function:
> > https://elixir.bootlin.com/linux/v5.8-rc4/source/drivers/firmware/arm_scmi/smc.c#L118
> >
> > But in the meantime scmi_rx_callback() has already been called. Not
> > sure if that's intentional or a possible bug.
> >
> >>
> >> Given that the kernel must somehow reserve this memory as a shared
> >> memory area for obvious reasons, and the trusted firmware must also
> >> ensure it treats this memory region with specific permissions in its
> >> translation regime, does it really make sense to give that much
> >> flexibility?

I share same opinion as Florian here.

[...]

> >> If your boot loader has FDT patching capability, maybe it can also do
> >> a SMC call to provide the address to your trusted firmware, prior to
> >> loading the Linux kernel, and then they both agree, prior to boot
> >> about the shared memory address?
> >
> > Yes, that's a possible solution, but it looks more complicated to me,
> > since it adds an additional component (the boot loader) to the
> > equation, while the goal of this patch was to reduce the coupling
> > between components (namely the DT/kernel and the trusted firmware).
> >
> > I guess my question is: if we fix the handling of LPAE addresses and
> > the SMC return code, what is the drawback of having the shmem address
> > passed to the SMC?
>
> My only concern is that if somehow Linux gets assigned a shared memory
> range that is completely outside of what the trusted firmware has
> already mapped, or is capable of addressing, or any combination thereof,
> it could be challenging to debug what is going on, especially if INVALID
> PARAMETER must not be returned (assuming this is to avoid Linux
> discovering where other shared memory areas pertaining to the firmware
> reside?).
>

Valid point. Again, I was planning to use this as identifier and didn't
think of the usecase Daniele mentions here.

> The other concern I have is that we are not documenting the various
> SMCCC calling conventions, soon enough it will be come out of control,
> and we are already allowing people to define their own function IDs and
> parameters to call into the trusted firmware. This sounds like something
> that is so basic that it should be standardized from the top, by ARM.
>

Completely agreed. I have failed to achieve that myself. Unless there is
demand from partners/vendors, it will be dismissed by architects. All
I managed to get in was the identifier as the argument for SMC/HVC to
support multiple channels. However 32-bit id will be issue to be used
with 64-bit address. I will see if we can drop that 32-bit requirement
from the spec.

> >
> > Anyway, I should have mentioned this in the commit message (sorry for
> > not doing so), but I submitted this patch because initial feedback from
> > Sudeep was positive [1]; but if there is no consensus around it I'm
> > fine with dropping it.
> >
> > [1] https://lore.kernel.org/lkml/20200710075931.GB1189@bogus/
>
> My review is by no means authoritative however in deploying SCMI on our
> Broadcom STB platforms some experience was gained in the process which
> is how it piqued my interest. Thanks for providing more background to
> this patch, this does help.
>

Your knowledge is important and please always share the same and happy
to take all your review into consideration always. End goal is to help
all or most of the users of the driver if possible.

> We have opted for a solution where the boot loader knows about all
> possible reserved regions prior to booting/loading the trusted firmware
> as well as the kernel, therefore it can pass that information to both
> and we never really had a situation where the two need to evolve in an
> uncoordinated way.

I agree and uncoordinated evolution may not be as simple as it is
presented by Daniele earlier and I am not confident to support that.
The main reason for giving positive response for this initially is
for the addition of identifier which I always thought is required for
supporting multiple channels. E.g. DVFS/Perf has dedicated channel.

--
Regards,
Sudeep

Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Sudeep Holla]

On Thu, Jul 16, 2020 at 12:57:23PM -0700, Florian Fainelli wrote:
>
>
> On 7/16/2020 7:13 AM, Daniele Alessandrelli wrote:
> > Hi Florian,
> >
> > Thanks for you feedback.
> >
> > On Wed, 2020-07-15 at 15:43 -0700, Florian Fainelli wrote:
> >>
> >> On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote:
> >>> From: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
> >>>
> >>> Currently, when SMC/HVC is used as transport, the base address of
> >>> the
> >>> shared memory used for communication is not passed to the SMCCC
> >>> call.
> >>> This means that such an address must be hard-coded into the
> >>> bootloader.
> >>>
> >>> In order to increase flexibility and allow the memory layout to be
> >>> changed without modifying the bootloader, this patch adds the
> >>> shared
> >>> memory base address to the a1 argument of the SMCCC call.
> >>>
> >>> On the Secure Monitor side, the service call implementation can
> >>> therefore read the a1 argument in order to know the location of the
> >>> shared memory to use. This change is backward compatible to
> >>> existing
> >>> service call implementations as long as they don't check for a1 to
> >>> be
> >>> zero.
> >>
> >> resource_size_t being defined after phys_addr_t, its size is
> >> different
> >> between 32-bit, 32-bit with PAE and 64-bit so it would probably make
> >> more sense to define an physical address alignment, or maybe an
> >> address
> >> that is in multiple of 4KBytes so you can address up to 36-bits of
> >> physical address even on a 32-bit only system?
> >
> > I see your point. After a quick look, I think that, practically, the
> > issue is with ARM32 LPAE addresses, for which phys_addr_t is a u64. So,
> > basically, for AArch32 systems with LPAE the 64-bit shmem_paddr gets
> > truncated to 32-bit when it's passed to the SMC32/HVC32 call.
> >
> > To solve that, I would prefer splitting the address between two SMC
> > parameters (a1 = addr_lo, a2 = addr_hi), instead of imposing an
> > arbitrary alignment. Would that be reasonable?
>
> The low/high part would only be relevant on a 32-bit LPAE platform which
> is probably a corner case, I would just pass the shmem_paddr / 4096
> since that is the smallest granule size and alignment possible and it
> still allows you to map up to 36-bits of physical address, which is the
> maximum that the long descriptor in LPAE can support. For 64-bit we have
> no such problems since we have the full register width.
>

OK, I will check if 32-bit identifier can be relaxed in the spec in which
case we can avoid having DT binding for the identifier. If that is possible
we could use addr/4k page size.

> >>
> >> What discovery mechanism does the OS have that the specified address
> >> within the SMCCC call has been accepted by the firmware given the
> >> return value of that SMCCC call does not appear to be used or checked? Do
> >> we just expect a timeout initializing the SCMI subsystem?
> >
> > The return code is actually checked at the end of the function:
> > https://elixir.bootlin.com/linux/v5.8-rc4/source/drivers/firmware/arm_scmi/smc.c#L118
> >
> > But in the meantime scmi_rx_callback() has already been called. Not
> > sure if that's intentional or a possible bug.
> >
> >>
> >> Given that the kernel must somehow reserve this memory as a shared
> >> memory area for obvious reasons, and the trusted firmware must also
> >> ensure it treats this memory region with specific permissions in its
> >> translation regime, does it really make sense to give that much
> >> flexibility?

I share same opinion as Florian here.

[...]

> >> If your boot loader has FDT patching capability, maybe it can also do
> >> a SMC call to provide the address to your trusted firmware, prior to
> >> loading the Linux kernel, and then they both agree, prior to boot
> >> about the shared memory address?
> >
> > Yes, that's a possible solution, but it looks more complicated to me,
> > since it adds an additional component (the boot loader) to the
> > equation, while the goal of this patch was to reduce the coupling
> > between components (namely the DT/kernel and the trusted firmware).
> >
> > I guess my question is: if we fix the handling of LPAE addresses and
> > the SMC return code, what is the drawback of having the shmem address
> > passed to the SMC?
>
> My only concern is that if somehow Linux gets assigned a shared memory
> range that is completely outside of what the trusted firmware has
> already mapped, or is capable of addressing, or any combination thereof,
> it could be challenging to debug what is going on, especially if INVALID
> PARAMETER must not be returned (assuming this is to avoid Linux
> discovering where other shared memory areas pertaining to the firmware
> reside?).
>

Valid point. Again, I was planning to use this as identifier and didn't
think of the usecase Daniele mentions here.

> The other concern I have is that we are not documenting the various
> SMCCC calling conventions, soon enough it will be come out of control,
> and we are already allowing people to define their own function IDs and
> parameters to call into the trusted firmware. This sounds like something
> that is so basic that it should be standardized from the top, by ARM.
>

Completely agreed. I have failed to achieve that myself. Unless there is
demand from partners/vendors, it will be dismissed by architects. All
I managed to get in was the identifier as the argument for SMC/HVC to
support multiple channels. However 32-bit id will be issue to be used
with 64-bit address. I will see if we can drop that 32-bit requirement
from the spec.

> >
> > Anyway, I should have mentioned this in the commit message (sorry for
> > not doing so), but I submitted this patch because initial feedback from
> > Sudeep was positive [1]; but if there is no consensus around it I'm
> > fine with dropping it.
> >
> > [1] https://lore.kernel.org/lkml/20200710075931.GB1189@bogus/
>
> My review is by no means authoritative however in deploying SCMI on our
> Broadcom STB platforms some experience was gained in the process which
> is how it piqued my interest. Thanks for providing more background to
> this patch, this does help.
>

Your knowledge is important and please always share the same and happy
to take all your review into consideration always. End goal is to help
all or most of the users of the driver if possible.

> We have opted for a solution where the boot loader knows about all
> possible reserved regions prior to booting/loading the trusted firmware
> as well as the kernel, therefore it can pass that information to both
> and we never really had a situation where the two need to evolve in an
> uncoordinated way.

I agree and uncoordinated evolution may not be as simple as it is
presented by Daniele earlier and I am not confident to support that.
The main reason for giving positive response for this initially is
for the addition of identifier which I always thought is required for
supporting multiple channels. E.g. DVFS/Perf has dedicated channel.

--
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Paul Murphy]

Hi Florian


On 7/16/20 20:57, Florian Fainelli wrote:

>>>
>>> Given that the kernel must somehow reserve this memory as a shared
>>> memory area for obvious reasons, and the trusted firmware must also
>>> ensure it treats this memory region with specific permissions in its
>>> translation regime, does it really make sense to give that much
>>> flexibility?
>>
>> Well, the trusted firmware might reserve a bigger region to be used for
>> other service as well. In other words, the MMU of TF-A is not necessary
>> specifically set up for this region, but, possibly, for a bigger
>> general shared region.
> 
> But presumably the Linux shared memory area should be mapped in a
> slightly different way than
> 


Sorry - could you clarify what you mean by that?

Just checking if we are doing everything correctly.

I didn't understand that there is a connection between the TF-A MMU 
tables for this region and the normal world MMU tables?

For example:

TF-A may map physical address range: 0x0 -> 0x400_000 as 'normal' memory 
for various purposes.

Linux SCMI driver could map physical address range, eg: 0x300_000 -> 
0x301_000 as IO memory for mailbox purpose only.

Is there any issue here?

Regards,

Paul

Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Paul Murphy]

Hi Florian


On 7/16/20 20:57, Florian Fainelli wrote:

>>>
>>> Given that the kernel must somehow reserve this memory as a shared
>>> memory area for obvious reasons, and the trusted firmware must also
>>> ensure it treats this memory region with specific permissions in its
>>> translation regime, does it really make sense to give that much
>>> flexibility?
>>
>> Well, the trusted firmware might reserve a bigger region to be used for
>> other service as well. In other words, the MMU of TF-A is not necessary
>> specifically set up for this region, but, possibly, for a bigger
>> general shared region.
> 
> But presumably the Linux shared memory area should be mapped in a
> slightly different way than
> 


Sorry - could you clarify what you mean by that?

Just checking if we are doing everything correctly.

I didn't understand that there is a connection between the TF-A MMU 
tables for this region and the normal world MMU tables?

For example:

TF-A may map physical address range: 0x0 -> 0x400_000 as 'normal' memory 
for various purposes.

Linux SCMI driver could map physical address range, eg: 0x300_000 -> 
0x301_000 as IO memory for mailbox purpose only.

Is there any issue here?

Regards,

Paul

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Daniele Alessandrelli]

On Thu, 2020-07-16 at 12:57 -0700, Florian Fainelli wrote:
> 
> On 7/16/2020 7:13 AM, Daniele Alessandrelli wrote:
> > Hi Florian,
> > 
> > Thanks for you feedback.
> > 
> > On Wed, 2020-07-15 at 15:43 -0700, Florian Fainelli wrote:
> > > On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote:
> > > > From: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
> > > > 
> > > > Currently, when SMC/HVC is used as transport, the base address
> > > > of
> > > > the
> > > > shared memory used for communication is not passed to the SMCCC
> > > > call.
> > > > This means that such an address must be hard-coded into the
> > > > bootloader.
> > > > 
> > > > In order to increase flexibility and allow the memory layout to
> > > > be
> > > > changed without modifying the bootloader, this patch adds the
> > > > shared
> > > > memory base address to the a1 argument of the SMCCC call.
> > > > 
> > > > On the Secure Monitor side, the service call implementation can
> > > > therefore read the a1 argument in order to know the location of
> > > > the
> > > > shared memory to use. This change is backward compatible to
> > > > existing
> > > > service call implementations as long as they don't check for a1
> > > > to
> > > > be
> > > > zero.
> > > 
> > > resource_size_t being defined after phys_addr_t, its size is
> > > different
> > > between 32-bit, 32-bit with PAE and 64-bit so it would probably
> > > make
> > > more sense to define an physical address alignment, or maybe an
> > > address
> > > that is in multiple of 4KBytes so you can address up to 36-bits
> > > of
> > > physical address even on a 32-bit only system?
> > 
> > I see your point. After a quick look, I think that, practically,
> > the
> > issue is with ARM32 LPAE addresses, for which phys_addr_t is a u64.
> > So,
> > basically, for AArch32 systems with LPAE the 64-bit shmem_paddr
> > gets
> > truncated to 32-bit when it's passed to the SMC32/HVC32 call.
> > 
> > To solve that, I would prefer splitting the address between two SMC
> > parameters (a1 = addr_lo, a2 = addr_hi), instead of imposing an
> > arbitrary alignment. Would that be reasonable?
> 
> The low/high part would only be relevant on a 32-bit LPAE platform
> which
> is probably a corner case, I would just pass the shmem_paddr / 4096
> since that is the smallest granule size and alignment possible and it
> still allows you to map up to 36-bits of physical address, which is
> the
> maximum that the long descriptor in LPAE can support. For 64-bit we
> have
> no such problems since we have the full register width.
> 
> > > What discovery mechanism does the OS have that the specified
> > > address
> > > within the SMCCC call has been accepted by the firmware given the
> > > return
> > > value of that SMCCC call does not appear to be used or checked?
> > > Do we
> > > just expect a timeout initializing the SCMI subsystem?
> > 
> > The return code is actually checked at the end of the function:
> > https://elixir.bootlin.com/linux/v5.8-rc4/source/drivers/firmware/arm_scmi/smc.c#L118
> > 
> > But in the meantime scmi_rx_callback() has already been called. Not
> > sure if that's intentional or a possible bug.
> > 
> > > Given that the kernel must somehow reserve this memory as a
> > > shared
> > > memory area for obvious reasons, and the trusted firmware must
> > > also
> > > ensure it treats this memory region with specific permissions in
> > > its
> > > translation regime, does it really make sense to give that much
> > > flexibility?
> > 
> > Well, the trusted firmware might reserve a bigger region to be used
> > for
> > other service as well. In other words, the MMU of TF-A is not
> > necessary
> > specifically set up for this region, but, possibly, for a bigger
> > general shared region.
> 
> But presumably the Linux shared memory area should be mapped in a
> slightly different way than
> 
> > Passing the SCMI shmem to the SMC call allows the shmem to be moved
> > within such bigger shared memory without modifying the trusted
> > firmware.
> > 
> > > If your boot loader has FDT patching capability, maybe it can
> > > also do
> > > a
> > > SMC call to provide the address to your trusted firmware, prior
> > > to
> > > loading the Linux kernel, and then they both agree, prior to boot
> > > about
> > > the shared memory address?
> > 
> > Yes, that's a possible solution, but it looks more complicated to
> > me,
> > since it adds an additional component (the boot loader) to the
> > equation, while the goal of this patch was to reduce the coupling
> > between components (namely the DT/kernel and the trusted firmware).
> > 
> > I guess my question is: if we fix the handling of LPAE addresses
> > and
> > the SMC return code, what is the drawback of having the shmem
> > address
> > passed to the SMC?
> 
> My only concern is that if somehow Linux gets assigned a shared
> memory
> range that is completely outside of what the trusted firmware has
> already mapped, or is capable of addressing, or any combination
> thereof,
> it could be challenging to debug what is going on, especially if
> INVALID
> PARAMETER must not be returned (assuming this is to avoid Linux
> discovering where other shared memory areas pertaining to the
> firmware
> reside?).
> 
> The other concern I have is that we are not documenting the various
> SMCCC calling conventions, soon enough it will be come out of
> control,
> and we are already allowing people to define their own function IDs
> and
> parameters to call into the trusted firmware. This sounds like
> something
> that is so basic that it should be standardized from the top, by ARM.

I agree. Having this standardized by ARM is probably what we really
need.

> 
> > Anyway, I should have mentioned this in the commit message (sorry
> > for
> > not doing so), but I submitted this patch because initial feedback
> > from
> > Sudeep was positive [1]; but if there is no consensus around it I'm
> > fine with dropping it.
> > 
> > [1] https://lore.kernel.org/lkml/20200710075931.GB1189@bogus/
> 
> My review is by no means authoritative however in deploying SCMI on
> our
> Broadcom STB platforms some experience was gained in the process
> which
> is how it piqued my interest. Thanks for providing more background to
> this patch, this does help.

Just to clarify, your review is very welcome and much appreciated.
Indeed, feedback from engineers with previous experience like yours is
really helpful. With the link above I didn't mean to dismiss your
feedback, but only to provide some background / context.

> 
> We have opted for a solution where the boot loader knows about all
> possible reserved regions prior to booting/loading the trusted
> firmware
> as well as the kernel, therefore it can pass that information to both
> and we never really had a situation where the two need to evolve in
> an
> uncoordinated way.

Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Daniele Alessandrelli]

On Thu, 2020-07-16 at 12:57 -0700, Florian Fainelli wrote:
> 
> On 7/16/2020 7:13 AM, Daniele Alessandrelli wrote:
> > Hi Florian,
> > 
> > Thanks for you feedback.
> > 
> > On Wed, 2020-07-15 at 15:43 -0700, Florian Fainelli wrote:
> > > On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote:
> > > > From: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
> > > > 
> > > > Currently, when SMC/HVC is used as transport, the base address
> > > > of
> > > > the
> > > > shared memory used for communication is not passed to the SMCCC
> > > > call.
> > > > This means that such an address must be hard-coded into the
> > > > bootloader.
> > > > 
> > > > In order to increase flexibility and allow the memory layout to
> > > > be
> > > > changed without modifying the bootloader, this patch adds the
> > > > shared
> > > > memory base address to the a1 argument of the SMCCC call.
> > > > 
> > > > On the Secure Monitor side, the service call implementation can
> > > > therefore read the a1 argument in order to know the location of
> > > > the
> > > > shared memory to use. This change is backward compatible to
> > > > existing
> > > > service call implementations as long as they don't check for a1
> > > > to
> > > > be
> > > > zero.
> > > 
> > > resource_size_t being defined after phys_addr_t, its size is
> > > different
> > > between 32-bit, 32-bit with PAE and 64-bit so it would probably
> > > make
> > > more sense to define an physical address alignment, or maybe an
> > > address
> > > that is in multiple of 4KBytes so you can address up to 36-bits
> > > of
> > > physical address even on a 32-bit only system?
> > 
> > I see your point. After a quick look, I think that, practically,
> > the
> > issue is with ARM32 LPAE addresses, for which phys_addr_t is a u64.
> > So,
> > basically, for AArch32 systems with LPAE the 64-bit shmem_paddr
> > gets
> > truncated to 32-bit when it's passed to the SMC32/HVC32 call.
> > 
> > To solve that, I would prefer splitting the address between two SMC
> > parameters (a1 = addr_lo, a2 = addr_hi), instead of imposing an
> > arbitrary alignment. Would that be reasonable?
> 
> The low/high part would only be relevant on a 32-bit LPAE platform
> which
> is probably a corner case, I would just pass the shmem_paddr / 4096
> since that is the smallest granule size and alignment possible and it
> still allows you to map up to 36-bits of physical address, which is
> the
> maximum that the long descriptor in LPAE can support. For 64-bit we
> have
> no such problems since we have the full register width.
> 
> > > What discovery mechanism does the OS have that the specified
> > > address
> > > within the SMCCC call has been accepted by the firmware given the
> > > return
> > > value of that SMCCC call does not appear to be used or checked?
> > > Do we
> > > just expect a timeout initializing the SCMI subsystem?
> > 
> > The return code is actually checked at the end of the function:
> > https://elixir.bootlin.com/linux/v5.8-rc4/source/drivers/firmware/arm_scmi/smc.c#L118
> > 
> > But in the meantime scmi_rx_callback() has already been called. Not
> > sure if that's intentional or a possible bug.
> > 
> > > Given that the kernel must somehow reserve this memory as a
> > > shared
> > > memory area for obvious reasons, and the trusted firmware must
> > > also
> > > ensure it treats this memory region with specific permissions in
> > > its
> > > translation regime, does it really make sense to give that much
> > > flexibility?
> > 
> > Well, the trusted firmware might reserve a bigger region to be used
> > for
> > other service as well. In other words, the MMU of TF-A is not
> > necessary
> > specifically set up for this region, but, possibly, for a bigger
> > general shared region.
> 
> But presumably the Linux shared memory area should be mapped in a
> slightly different way than
> 
> > Passing the SCMI shmem to the SMC call allows the shmem to be moved
> > within such bigger shared memory without modifying the trusted
> > firmware.
> > 
> > > If your boot loader has FDT patching capability, maybe it can
> > > also do
> > > a
> > > SMC call to provide the address to your trusted firmware, prior
> > > to
> > > loading the Linux kernel, and then they both agree, prior to boot
> > > about
> > > the shared memory address?
> > 
> > Yes, that's a possible solution, but it looks more complicated to
> > me,
> > since it adds an additional component (the boot loader) to the
> > equation, while the goal of this patch was to reduce the coupling
> > between components (namely the DT/kernel and the trusted firmware).
> > 
> > I guess my question is: if we fix the handling of LPAE addresses
> > and
> > the SMC return code, what is the drawback of having the shmem
> > address
> > passed to the SMC?
> 
> My only concern is that if somehow Linux gets assigned a shared
> memory
> range that is completely outside of what the trusted firmware has
> already mapped, or is capable of addressing, or any combination
> thereof,
> it could be challenging to debug what is going on, especially if
> INVALID
> PARAMETER must not be returned (assuming this is to avoid Linux
> discovering where other shared memory areas pertaining to the
> firmware
> reside?).
> 
> The other concern I have is that we are not documenting the various
> SMCCC calling conventions, soon enough it will be come out of
> control,
> and we are already allowing people to define their own function IDs
> and
> parameters to call into the trusted firmware. This sounds like
> something
> that is so basic that it should be standardized from the top, by ARM.

I agree. Having this standardized by ARM is probably what we really
need.

> 
> > Anyway, I should have mentioned this in the commit message (sorry
> > for
> > not doing so), but I submitted this patch because initial feedback
> > from
> > Sudeep was positive [1]; but if there is no consensus around it I'm
> > fine with dropping it.
> > 
> > [1] https://lore.kernel.org/lkml/20200710075931.GB1189@bogus/
> 
> My review is by no means authoritative however in deploying SCMI on
> our
> Broadcom STB platforms some experience was gained in the process
> which
> is how it piqued my interest. Thanks for providing more background to
> this patch, this does help.

Just to clarify, your review is very welcome and much appreciated.
Indeed, feedback from engineers with previous experience like yours is
really helpful. With the link above I didn't mean to dismiss your
feedback, but only to provide some background / context.

> 
> We have opted for a solution where the boot loader knows about all
> possible reserved regions prior to booting/loading the trusted
> firmware
> as well as the kernel, therefore it can pass that information to both
> and we never really had a situation where the two need to evolve in
> an
> uncoordinated way.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Daniele Alessandrelli]

On Fri, 2020-07-17 at 11:31 +0100, Sudeep Holla wrote:
> On Thu, Jul 16, 2020 at 12:57:23PM -0700, Florian Fainelli wrote:
> > 
> > On 7/16/2020 7:13 AM, Daniele Alessandrelli wrote:
> > > Hi Florian,
> > > 
> > > Thanks for you feedback.
> > > 
> > > On Wed, 2020-07-15 at 15:43 -0700, Florian Fainelli wrote:
> > > > On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote:
> > > > > From: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
> > > > > 
> > > > > Currently, when SMC/HVC is used as transport, the base
> > > > > address of
> > > > > the
> > > > > shared memory used for communication is not passed to the
> > > > > SMCCC
> > > > > call.
> > > > > This means that such an address must be hard-coded into the
> > > > > bootloader.
> > > > > 
> > > > > In order to increase flexibility and allow the memory layout
> > > > > to be
> > > > > changed without modifying the bootloader, this patch adds the
> > > > > shared
> > > > > memory base address to the a1 argument of the SMCCC call.
> > > > > 
> > > > > On the Secure Monitor side, the service call implementation
> > > > > can
> > > > > therefore read the a1 argument in order to know the location
> > > > > of the
> > > > > shared memory to use. This change is backward compatible to
> > > > > existing
> > > > > service call implementations as long as they don't check for
> > > > > a1 to
> > > > > be
> > > > > zero.
> > > > 
> > > > resource_size_t being defined after phys_addr_t, its size is
> > > > different
> > > > between 32-bit, 32-bit with PAE and 64-bit so it would probably
> > > > make
> > > > more sense to define an physical address alignment, or maybe an
> > > > address
> > > > that is in multiple of 4KBytes so you can address up to 36-bits 
> > > > of
> > > > physical address even on a 32-bit only system?
> > > 
> > > I see your point. After a quick look, I think that, practically,
> > > the
> > > issue is with ARM32 LPAE addresses, for which phys_addr_t is a
> > > u64. So,
> > > basically, for AArch32 systems with LPAE the 64-bit shmem_paddr
> > > gets
> > > truncated to 32-bit when it's passed to the SMC32/HVC32 call.
> > > 
> > > To solve that, I would prefer splitting the address between two
> > > SMC
> > > parameters (a1 = addr_lo, a2 = addr_hi), instead of imposing an
> > > arbitrary alignment. Would that be reasonable?
> > 
> > The low/high part would only be relevant on a 32-bit LPAE platform
> > which
> > is probably a corner case, I would just pass the shmem_paddr / 4096
> > since that is the smallest granule size and alignment possible and
> > it
> > still allows you to map up to 36-bits of physical address, which is
> > the
> > maximum that the long descriptor in LPAE can support. For 64-bit we
> > have
> > no such problems since we have the full register width.
> > 
> 
> OK, I will check if 32-bit identifier can be relaxed in the spec in
> which
> case we can avoid having DT binding for the identifier. If that is
> possible
> we could use addr/4k page size.
> 
> > > > What discovery mechanism does the OS have that the specified
> > > > address
> > > > within the SMCCC call has been accepted by the firmware given
> > > > the
> > > > return value of that SMCCC call does not appear to be used or
> > > > checked? Do
> > > > we just expect a timeout initializing the SCMI subsystem?
> > > 
> > > The return code is actually checked at the end of the function:
> > > https://elixir.bootlin.com/linux/v5.8-rc4/source/drivers/firmware/arm_scmi/smc.c#L118
> > > 
> > > But in the meantime scmi_rx_callback() has already been called.
> > > Not
> > > sure if that's intentional or a possible bug.
> > > 
> > > > Given that the kernel must somehow reserve this memory as a
> > > > shared
> > > > memory area for obvious reasons, and the trusted firmware must
> > > > also
> > > > ensure it treats this memory region with specific permissions
> > > > in its
> > > > translation regime, does it really make sense to give that much
> > > > flexibility?
> 
> I share same opinion as Florian here.
> 
> [...]
> 
> > > > If your boot loader has FDT patching capability, maybe it can
> > > > also do
> > > > a SMC call to provide the address to your trusted firmware,
> > > > prior to
> > > > loading the Linux kernel, and then they both agree, prior to
> > > > boot
> > > > about the shared memory address?
> > > 
> > > Yes, that's a possible solution, but it looks more complicated to
> > > me,
> > > since it adds an additional component (the boot loader) to the
> > > equation, while the goal of this patch was to reduce the coupling
> > > between components (namely the DT/kernel and the trusted
> > > firmware).
> > > 
> > > I guess my question is: if we fix the handling of LPAE addresses
> > > and
> > > the SMC return code, what is the drawback of having the shmem
> > > address
> > > passed to the SMC?
> > 
> > My only concern is that if somehow Linux gets assigned a shared
> > memory
> > range that is completely outside of what the trusted firmware has
> > already mapped, or is capable of addressing, or any combination
> > thereof,
> > it could be challenging to debug what is going on, especially if
> > INVALID
> > PARAMETER must not be returned (assuming this is to avoid Linux
> > discovering where other shared memory areas pertaining to the
> > firmware
> > reside?).
> > 
> 
> Valid point. Again, I was planning to use this as identifier and
> didn't
> think of the usecase Daniele mentions here.
> 
> > The other concern I have is that we are not documenting the various
> > SMCCC calling conventions, soon enough it will be come out of
> > control,
> > and we are already allowing people to define their own function IDs
> > and
> > parameters to call into the trusted firmware. This sounds like
> > something
> > that is so basic that it should be standardized from the top, by
> > ARM.
> > 
> 
> Completely agreed. I have failed to achieve that myself. Unless there
> is
> demand from partners/vendors, it will be dismissed by architects. All
> I managed to get in was the identifier as the argument for SMC/HVC to
> support multiple channels. However 32-bit id will be issue to be used
> with 64-bit address. I will see if we can drop that 32-bit
> requirement
> from the spec.

It seems that there is some demand already, but perhaps it needs to be
requested in a more official way? What is the recommended way to do so?

> 
> > > Anyway, I should have mentioned this in the commit message (sorry
> > > for
> > > not doing so), but I submitted this patch because initial
> > > feedback from
> > > Sudeep was positive [1]; but if there is no consensus around it
> > > I'm
> > > fine with dropping it.
> > > 
> > > [1] https://lore.kernel.org/lkml/20200710075931.GB1189@bogus/
> > 
> > My review is by no means authoritative however in deploying SCMI on
> > our
> > Broadcom STB platforms some experience was gained in the process
> > which
> > is how it piqued my interest. Thanks for providing more background
> > to
> > this patch, this does help.
> > 
> 
> Your knowledge is important and please always share the same and
> happy
> to take all your review into consideration always. End goal is to
> help
> all or most of the users of the driver if possible.
> 
> > We have opted for a solution where the boot loader knows about all
> > possible reserved regions prior to booting/loading the trusted
> > firmware
> > as well as the kernel, therefore it can pass that information to
> > both
> > and we never really had a situation where the two need to evolve in
> > an
> > uncoordinated way.
> 
> I agree and uncoordinated evolution may not be as simple as it is
> presented by Daniele earlier and I am not confident to support that.
> The main reason for giving positive response for this initially is
> for the addition of identifier which I always thought is required for
> supporting multiple channels. E.g. DVFS/Perf has dedicated channel.

I can see now that in the previous discussion there was some
misunderstanding on the intended use case. That's fine, I will drop the
patch for now, since hard-coding the shmem address in our trusted
firmware is fine with us (and so we don't really need this patch).

> 
> --
> Regards,
> Sudeep

Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Daniele Alessandrelli]

On Fri, 2020-07-17 at 11:31 +0100, Sudeep Holla wrote:
> On Thu, Jul 16, 2020 at 12:57:23PM -0700, Florian Fainelli wrote:
> > 
> > On 7/16/2020 7:13 AM, Daniele Alessandrelli wrote:
> > > Hi Florian,
> > > 
> > > Thanks for you feedback.
> > > 
> > > On Wed, 2020-07-15 at 15:43 -0700, Florian Fainelli wrote:
> > > > On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote:
> > > > > From: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
> > > > > 
> > > > > Currently, when SMC/HVC is used as transport, the base
> > > > > address of
> > > > > the
> > > > > shared memory used for communication is not passed to the
> > > > > SMCCC
> > > > > call.
> > > > > This means that such an address must be hard-coded into the
> > > > > bootloader.
> > > > > 
> > > > > In order to increase flexibility and allow the memory layout
> > > > > to be
> > > > > changed without modifying the bootloader, this patch adds the
> > > > > shared
> > > > > memory base address to the a1 argument of the SMCCC call.
> > > > > 
> > > > > On the Secure Monitor side, the service call implementation
> > > > > can
> > > > > therefore read the a1 argument in order to know the location
> > > > > of the
> > > > > shared memory to use. This change is backward compatible to
> > > > > existing
> > > > > service call implementations as long as they don't check for
> > > > > a1 to
> > > > > be
> > > > > zero.
> > > > 
> > > > resource_size_t being defined after phys_addr_t, its size is
> > > > different
> > > > between 32-bit, 32-bit with PAE and 64-bit so it would probably
> > > > make
> > > > more sense to define an physical address alignment, or maybe an
> > > > address
> > > > that is in multiple of 4KBytes so you can address up to 36-bits 
> > > > of
> > > > physical address even on a 32-bit only system?
> > > 
> > > I see your point. After a quick look, I think that, practically,
> > > the
> > > issue is with ARM32 LPAE addresses, for which phys_addr_t is a
> > > u64. So,
> > > basically, for AArch32 systems with LPAE the 64-bit shmem_paddr
> > > gets
> > > truncated to 32-bit when it's passed to the SMC32/HVC32 call.
> > > 
> > > To solve that, I would prefer splitting the address between two
> > > SMC
> > > parameters (a1 = addr_lo, a2 = addr_hi), instead of imposing an
> > > arbitrary alignment. Would that be reasonable?
> > 
> > The low/high part would only be relevant on a 32-bit LPAE platform
> > which
> > is probably a corner case, I would just pass the shmem_paddr / 4096
> > since that is the smallest granule size and alignment possible and
> > it
> > still allows you to map up to 36-bits of physical address, which is
> > the
> > maximum that the long descriptor in LPAE can support. For 64-bit we
> > have
> > no such problems since we have the full register width.
> > 
> 
> OK, I will check if 32-bit identifier can be relaxed in the spec in
> which
> case we can avoid having DT binding for the identifier. If that is
> possible
> we could use addr/4k page size.
> 
> > > > What discovery mechanism does the OS have that the specified
> > > > address
> > > > within the SMCCC call has been accepted by the firmware given
> > > > the
> > > > return value of that SMCCC call does not appear to be used or
> > > > checked? Do
> > > > we just expect a timeout initializing the SCMI subsystem?
> > > 
> > > The return code is actually checked at the end of the function:
> > > https://elixir.bootlin.com/linux/v5.8-rc4/source/drivers/firmware/arm_scmi/smc.c#L118
> > > 
> > > But in the meantime scmi_rx_callback() has already been called.
> > > Not
> > > sure if that's intentional or a possible bug.
> > > 
> > > > Given that the kernel must somehow reserve this memory as a
> > > > shared
> > > > memory area for obvious reasons, and the trusted firmware must
> > > > also
> > > > ensure it treats this memory region with specific permissions
> > > > in its
> > > > translation regime, does it really make sense to give that much
> > > > flexibility?
> 
> I share same opinion as Florian here.
> 
> [...]
> 
> > > > If your boot loader has FDT patching capability, maybe it can
> > > > also do
> > > > a SMC call to provide the address to your trusted firmware,
> > > > prior to
> > > > loading the Linux kernel, and then they both agree, prior to
> > > > boot
> > > > about the shared memory address?
> > > 
> > > Yes, that's a possible solution, but it looks more complicated to
> > > me,
> > > since it adds an additional component (the boot loader) to the
> > > equation, while the goal of this patch was to reduce the coupling
> > > between components (namely the DT/kernel and the trusted
> > > firmware).
> > > 
> > > I guess my question is: if we fix the handling of LPAE addresses
> > > and
> > > the SMC return code, what is the drawback of having the shmem
> > > address
> > > passed to the SMC?
> > 
> > My only concern is that if somehow Linux gets assigned a shared
> > memory
> > range that is completely outside of what the trusted firmware has
> > already mapped, or is capable of addressing, or any combination
> > thereof,
> > it could be challenging to debug what is going on, especially if
> > INVALID
> > PARAMETER must not be returned (assuming this is to avoid Linux
> > discovering where other shared memory areas pertaining to the
> > firmware
> > reside?).
> > 
> 
> Valid point. Again, I was planning to use this as identifier and
> didn't
> think of the usecase Daniele mentions here.
> 
> > The other concern I have is that we are not documenting the various
> > SMCCC calling conventions, soon enough it will be come out of
> > control,
> > and we are already allowing people to define their own function IDs
> > and
> > parameters to call into the trusted firmware. This sounds like
> > something
> > that is so basic that it should be standardized from the top, by
> > ARM.
> > 
> 
> Completely agreed. I have failed to achieve that myself. Unless there
> is
> demand from partners/vendors, it will be dismissed by architects. All
> I managed to get in was the identifier as the argument for SMC/HVC to
> support multiple channels. However 32-bit id will be issue to be used
> with 64-bit address. I will see if we can drop that 32-bit
> requirement
> from the spec.

It seems that there is some demand already, but perhaps it needs to be
requested in a more official way? What is the recommended way to do so?

> 
> > > Anyway, I should have mentioned this in the commit message (sorry
> > > for
> > > not doing so), but I submitted this patch because initial
> > > feedback from
> > > Sudeep was positive [1]; but if there is no consensus around it
> > > I'm
> > > fine with dropping it.
> > > 
> > > [1] https://lore.kernel.org/lkml/20200710075931.GB1189@bogus/
> > 
> > My review is by no means authoritative however in deploying SCMI on
> > our
> > Broadcom STB platforms some experience was gained in the process
> > which
> > is how it piqued my interest. Thanks for providing more background
> > to
> > this patch, this does help.
> > 
> 
> Your knowledge is important and please always share the same and
> happy
> to take all your review into consideration always. End goal is to
> help
> all or most of the users of the driver if possible.
> 
> > We have opted for a solution where the boot loader knows about all
> > possible reserved regions prior to booting/loading the trusted
> > firmware
> > as well as the kernel, therefore it can pass that information to
> > both
> > and we never really had a situation where the two need to evolve in
> > an
> > uncoordinated way.
> 
> I agree and uncoordinated evolution may not be as simple as it is
> presented by Daniele earlier and I am not confident to support that.
> The main reason for giving positive response for this initially is
> for the addition of identifier which I always thought is required for
> supporting multiple channels. E.g. DVFS/Perf has dedicated channel.

I can see now that in the previous discussion there was some
misunderstanding on the intended use case. That's fine, I will drop the
patch for now, since hard-coding the shmem address in our trusted
firmware is fine with us (and so we don't really need this patch).

> 
> --
> Regards,
> Sudeep


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Florian Fainelli]

On 7/17/2020 2:45 AM, Sudeep Holla wrote:
> On Wed, Jul 15, 2020 at 03:43:24PM -0700, Florian Fainelli wrote:
>>
>>
>> On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote:
>>> From: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
>>>
>>> Currently, when SMC/HVC is used as transport, the base address of the
>>> shared memory used for communication is not passed to the SMCCC call.
>>> This means that such an address must be hard-coded into the bootloader.
>>>
>>> In order to increase flexibility and allow the memory layout to be
>>> changed without modifying the bootloader, this patch adds the shared
>>> memory base address to the a1 argument of the SMCCC call.
>>>
>>> On the Secure Monitor side, the service call implementation can
>>> therefore read the a1 argument in order to know the location of the
>>> shared memory to use. This change is backward compatible to existing
>>> service call implementations as long as they don't check for a1 to be
>>> zero.
>>
>> resource_size_t being defined after phys_addr_t, its size is different
>> between 32-bit, 32-bit with PAE and 64-bit so it would probably make
>> more sense to define an physical address alignment, or maybe an address
>> that is in multiple of 4KBytes so you can address up to 36-bits of
>> physical address even on a 32-bit only system?
>>
> 
> Good point, I had forgotten about LPAE. Thanks for pointing it out.
> 
>> What discovery mechanism does the OS have that the specified address
>> within the SMCCC call has been accepted by the firmware given the return
>> value of that SMCCC call does not appear to be used or checked? Do we
>> just expect a timeout initializing the SCMI subsystem?
>>
> 
> Agreed, we need to add the check for proper return value then and
> definitely document it very clearly as we are trying to standardise
> a call to vendor SiP FID space of SMCCC.
> 
>> Given that the kernel must somehow reserve this memory as a shared
>> memory area for obvious reasons, and the trusted firmware must also
>> ensure it treats this memory region with specific permissions in its
>> translation regime, does it really make sense to give that much flexibility?
>>
> 
> I expect so and this comes as shmem property from DT already. We are
> just passing the value obtained from there as is. This is just to help
> TFA or the firmware to identify the specific channel/shmem as SMC/HVC
> otherwise has no way to do so.

OK, that is fair enough.

> 
>> If your boot loader has FDT patching capability, maybe it can also do a
>> SMC call to provide the address to your trusted firmware, prior to
>> loading the Linux kernel, and then they both agree, prior to boot about
>> the shared memory address?
>>
> 
> Yes, but we definitely can't rely on such mechanism in the kernel. It is
> more a platform choice as they run different bootloaders.
> 

That argument can be be used the other way too if this is a platform
choice, the platform boot loader can ensure that both ends of the SMC
agree on the shared memory region. I do see an advantage to the approach
being suggested here that the shared memory does not necessarily need to
be mapped by the TF prior to Linux booting, but it can be deferred until
when Linux makes the first SMC call but that may require more complexity
on the TF side to issue an appropriate MMU update, so maybe from a
security perspective this is more dangerous..

Alright, I am convinced now this is useful :)
-- 
Florian

Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Florian Fainelli]

On 7/17/2020 2:45 AM, Sudeep Holla wrote:
> On Wed, Jul 15, 2020 at 03:43:24PM -0700, Florian Fainelli wrote:
>>
>>
>> On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote:
>>> From: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
>>>
>>> Currently, when SMC/HVC is used as transport, the base address of the
>>> shared memory used for communication is not passed to the SMCCC call.
>>> This means that such an address must be hard-coded into the bootloader.
>>>
>>> In order to increase flexibility and allow the memory layout to be
>>> changed without modifying the bootloader, this patch adds the shared
>>> memory base address to the a1 argument of the SMCCC call.
>>>
>>> On the Secure Monitor side, the service call implementation can
>>> therefore read the a1 argument in order to know the location of the
>>> shared memory to use. This change is backward compatible to existing
>>> service call implementations as long as they don't check for a1 to be
>>> zero.
>>
>> resource_size_t being defined after phys_addr_t, its size is different
>> between 32-bit, 32-bit with PAE and 64-bit so it would probably make
>> more sense to define an physical address alignment, or maybe an address
>> that is in multiple of 4KBytes so you can address up to 36-bits of
>> physical address even on a 32-bit only system?
>>
> 
> Good point, I had forgotten about LPAE. Thanks for pointing it out.
> 
>> What discovery mechanism does the OS have that the specified address
>> within the SMCCC call has been accepted by the firmware given the return
>> value of that SMCCC call does not appear to be used or checked? Do we
>> just expect a timeout initializing the SCMI subsystem?
>>
> 
> Agreed, we need to add the check for proper return value then and
> definitely document it very clearly as we are trying to standardise
> a call to vendor SiP FID space of SMCCC.
> 
>> Given that the kernel must somehow reserve this memory as a shared
>> memory area for obvious reasons, and the trusted firmware must also
>> ensure it treats this memory region with specific permissions in its
>> translation regime, does it really make sense to give that much flexibility?
>>
> 
> I expect so and this comes as shmem property from DT already. We are
> just passing the value obtained from there as is. This is just to help
> TFA or the firmware to identify the specific channel/shmem as SMC/HVC
> otherwise has no way to do so.

OK, that is fair enough.

> 
>> If your boot loader has FDT patching capability, maybe it can also do a
>> SMC call to provide the address to your trusted firmware, prior to
>> loading the Linux kernel, and then they both agree, prior to boot about
>> the shared memory address?
>>
> 
> Yes, but we definitely can't rely on such mechanism in the kernel. It is
> more a platform choice as they run different bootloaders.
> 

That argument can be be used the other way too if this is a platform
choice, the platform boot loader can ensure that both ends of the SMC
agree on the shared memory region. I do see an advantage to the approach
being suggested here that the shared memory does not necessarily need to
be mapped by the TF prior to Linux booting, but it can be deferred until
when Linux makes the first SMC call but that may require more complexity
on the TF side to issue an appropriate MMU update, so maybe from a
security perspective this is more dangerous..

Alright, I am convinced now this is useful :)
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel