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.euhttp://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