Hello,
There's an effort inside of Google to make builds more hermetic across the board. One of the challenges we ran into was supporting the transitive dependencies of generate_test_list.pl, namely XML::LibXML. Since this isn't in the perl standard library, we have to add what amounts to an entire sysroot with a bunch of dependencies just to support this one library. Not impossible (and to be clear, this is the route that we went with), but not ideal either.
Another approach that we explored was rewriting generate_test_list.pl in python. XML parsing is in python's standard library and many of our engineers are more familiar with it, so we thought this would be a reasonable choice. We wrote the script, and it seems to work (with some caveats that I'll discuss below). However, we don't want to diverge from upstream, hence why I'm here :).
The script is approximately the same length as the original script and supports all of the same features and checking, with one catch. The standard library's XML parsing module doesn't support entity expansion, which is a feature used in many places within TFTF (see, for example, tests-standard.xml). This is done for security reasons and I haven't found a way around it without resorting to xml parsers outside of the standard library (which kinda defeats the purpose). To resolve this, we use xincludes instead, meaning that tests-standard.xml (for example) would have to be rewritten to use the new syntax.
For example, tests-standard.xml would look like the following:
<document>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="tests-tftf-validation.xml"/>
... rest of includes here...
</document>
Any thoughts on this? If you're okay with this approach we can put our CL up for review.
We also experimented with doing some hand-parsing to support entity expansion and I suspect that there's *some* way to convince entity expansion to occur within the standard library, but wanted to take your temperature on the above changes before pursuing those further.
Thanks,
Jim
TF-A Community,
This is to notify that we are planning to target the Trusted Firmware-A 2.9 release during the middle of May 2023 as part of the regular 6 month cadence.
The aim is to consolidate all TF-A work since the 2.8 release. As part of this, a release candidate tag is targeted to be created and release activities commence from 10th May 2023 across all TF-A repositories.
Essentially we will not merge any major enhancements from this date until the release is made.
Please ensure any patches desired to make the 2.9 release are submitted in good time to be complete by 9th May 2023.
Any major enhancement patches still open after that date will not be merged until after the release.
This will involve the various repositories making up the broader TF-A project including the TF-A mainline, TF-A Tests, Hafnium, TF-A CI Scripts and TF-A CI Job. In addition a TF-RMM repository release will be made that is compatible with v2.9.
We will endeavour minimise the disruption on patch merging and complete release activities ASAP after we start normally completing within 7-10 working days.
Regards
Joanna Farley
HI, tf-a-test community,
I have one question about the smmuv3 testing on fvp.
Below is the SMMUV3 related parameters passed to fvp suggested in https://trustedfirmware-a.readthedocs.io/en/latest/components/realm-managem… to enable 3rd world options for RME (CCA).
pci.pci_smmuv3.mmu.SMMU_ROOT_IDR0=3
pci.pci_smmuv3.mmu.SMMU_ROOT_IIDR=0x43B
pci.pci_smmuv3.mmu.root_register_page_offset=0x20000
What I want to try with fvp with SMMU is generating transactions from the peripheral devices through the SMMU to access some memory ranges.
I found that FVP doesn’t have any peripherals connected through the SMMU, shown in the dts file in the linux repository for FVP, except PCIe (i.e., pci: pci@40000000 in fvp-base-revc.dts)
Is there any way that I can attach any peripherals through the SMMU or generate transactions to SMMU directly to make SMMU walks the stream table, which allows the device to access memories?
I checked the spm/cactus/cactus_tests/cactus_tests_smmuv3.c
But seems that this test case is not executable on the fvp? I got the “FFA_VERSION” not supported error message.
Moreover, it seems that this test just send command to emulated smmutesting engine and do memcopy operation.
I cannot understand how does it work even without initializing stream table (as far as I know it is initialized with kernel driver).
Sincerely
Jaehyuk
