Hi Michal

As per spec, bits 23:17 are all reserved and it should either be all 0's or all 1's(Armv7 legacy TOS). So based on this guideline xilinx's range of 0x820e0001- 0x820e0003 is wrong and would appreciate if you could push a patch for this.

Regarding SVE hint bit 16, which shall be masked out (or ignored) by the SiP service. There is a patch to SVE hint bit information down to dispatchers through the SMC flags field [1].
A dispatcher can choose to ignore or consume it (as long as SVE is preserved across calls) like done in [2]. So, for your case you don't need to do anything.

We are having an internal discussion to introduce a sanity check in generic TF-A code to ensure bits 23:17 are either all 0's or all 1's for a Fast SMC (Table 2.1), we will post a patch if we decide to go ahead with it.

[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17511
[2] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17512

Thanks
Manish
From: Michal Simek via TF-A <tf-a@lists.trustedfirmware.org>
Sent: 14 February 2023 08:15
To: tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.org>
Subject: [TF-A] Checking SIP Service Calls range
 
Hi,

I have one question about SIP Service Calls range and it's range checking.
Based on DEN0028E SIP Service Calls ranges are
0x82000000-0x8200FFFF SMC32: SiP Service Calls
0xC2000000-0xC200FFFF SMC64: SiP Service Calls

That's the ranges which we are using for implementing SOC specific SMC handlers
and I found that in past it was also added code which is out of this range.

Specifically in Xilinx ZynqMP you can see code like this

        if (is_em_fid(smc_fid)) {
                return em_smc_handler(smc_fid, x1, x2, x3, x4, cookie, handle,
                                        flags);
        }

where EM range is 0x820e0001- 0x820e0003 is out of our range which is assigned
to us. But there is no failure at all that we are out of ranged in spec.
Shouldn't this be enforced by core itself?

That's why I just wanted to know your opinion about it. We will definitely
implement better masking to find out that 0x00fe0000 are all zeros.
But that bit 16 is based on DEN0028E related to smcccv1.3 which I think we are
not supporting now that's why should be 0 too.
But definitely some information about this bit should be useful.

Thanks,
Michal


--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs

--
TF-A mailing list -- tf-a@lists.trustedfirmware.org
To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org