Hi Olivier/Andrew,
> On 22 Jul 2020, at 15:08, Andrew Walbran via Hafnium <hafnium(a)lists.trustedfirmware.org> wrote:
>
> On Wed, 22 Jul 2020 at 15:01, Olivier Deprez via Hafnium <
> hafnium(a)lists.trustedfirmware.org> wrote:
>
>> Hi,
>>
>> We noticed api_ffa_features returns FFA_SUCCESS_32 for all implemented
>> ABIs with the SMC32 convention, but FFA_RXTX_MAP_64:
>> https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1430
Did you mean : https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1510
>>
>> On the other hand ffa_handler discards the SMC convention bit:
>>
>> https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/h…
What is the rationale behind this? As per the SMCCC: -1 must be returned for an SMC64/HVC64 call from AArch32 state or an unknown function ID. In the latter case, if the spec don’t list it then it ain’t there :)
>>
>> It means one can call FFA_FEATURES(FFA_RXTX_MAP_32) which will fail,
>> although this does not prevent effectively calling the same ABI with the
>> SMC32 convention.
>>
>> Is there some fine tuning to do here?
>> Should we just discard the SMC convention bit in api_ffa_features?
>>
>
> I don't think FFA_RXTX_MAP_32 will work, because we need 64-bit addresses
> for the buffers that it passes. We should probably return an error from
> ffa_handler if a VM tries to call FFA_RXTX_MAP_32.
Does Hafnium not intend to work with AArch32 SPs? Is this is a requirement that has been spelt out so the community ensures no AArch32 SPs are presented. The SPM design doc catered for this requirement the last time I checked.
>
> For other functions I guess we could make it support either, by discarding
> the SMC convention bit in FFA_FEATURES as you suggest. Are there any other
> differences between the SMC32 and SMC64 convention which we need to take
> care of?
I think we need to make a more informed choice. For example, what if FFA_FEATURES is called with the non-existent 64-bit FID for FFA_ID_GET, FFA_RXTX_UNMAP, FFA_PARTITION_INFO_GET, FFA_MEM_FRAG_RX, FFA_MEM_FRAG_TX etc.
Cheers,
Achin
> --
> Hafnium mailing list
> Hafnium(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/hafnium
On Wed, 22 Jul 2020 at 15:01, Olivier Deprez via Hafnium <
hafnium(a)lists.trustedfirmware.org> wrote:
> Hi,
>
> We noticed api_ffa_features returns FFA_SUCCESS_32 for all implemented
> ABIs with the SMC32 convention, but FFA_RXTX_MAP_64:
> https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1430
>
> On the other hand ffa_handler discards the SMC convention bit:
>
> https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/h…
>
> It means one can call FFA_FEATURES(FFA_RXTX_MAP_32) which will fail,
> although this does not prevent effectively calling the same ABI with the
> SMC32 convention.
>
> Is there some fine tuning to do here?
> Should we just discard the SMC convention bit in api_ffa_features?
>
I don't think FFA_RXTX_MAP_32 will work, because we need 64-bit addresses
for the buffers that it passes. We should probably return an error from
ffa_handler if a VM tries to call FFA_RXTX_MAP_32.
For other functions I guess we could make it support either, by discarding
the SMC convention bit in FFA_FEATURES as you suggest. Are there any other
differences between the SMC32 and SMC64 convention which we need to take
care of?
Hi,
We noticed api_ffa_features returns FFA_SUCCESS_32 for all implemented ABIs with the SMC32 convention, but FFA_RXTX_MAP_64:
https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1430
On the other hand ffa_handler discards the SMC convention bit:
https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/h…
It means one can call FFA_FEATURES(FFA_RXTX_MAP_32) which will fail,
although this does not prevent effectively calling the same ABI with the SMC32 convention.
Is there some fine tuning to do here?
Should we just discard the SMC convention bit in api_ffa_features?
Regards,
Olivier.
Yep, mm_vm_dump sounds like what you're looking for. You can add a call
where you like and it will go to the log UART.
On Thu, 16 Jul 2020 at 19:14, Raghu K via Hafnium <
hafnium(a)lists.trustedfirmware.org> wrote:
> Quick search indicates mm_vm_dump() and the functions it calls in
> src/mm.c should do what you want. i've not tried it or don't know the
> format, but this may be what you are looking for.
>
> -Raghu
>
> On 7/16/20 11:03 AM, Madhukar Pappireddy via Hafnium wrote:
> > Hi,
> >
> > I was wondering if there is support in Hafnium to dump page tables to a
> log file. I am new to the Hafnium project and would appreciate any help.
> Below is an example from TF-A which provides such provision.
> >
> > ......<snip>
> > VERBOSE: Translation tables state:
> > VERBOSE: Xlat regime: EL3
> > VERBOSE: Max allowed PA: 0xfffffffff
> > VERBOSE: Max allowed VA: 0xfffffffff
> > VERBOSE: Max mapped PA: 0x2f1fffff
> > VERBOSE: Max mapped VA: 0x2f1fffff
> > VERBOSE: Initial lookup level: 1
> > VERBOSE: Entries @initial lookup level: 64
> > VERBOSE: Used 3 sub-tables out of 5 (spare: 2)
> > [LV1] VA:0x0 size:0x40000000
> > [LV2] VA:0x0 size:0x200000
> > [LV3] VA:0x0 PA:0x0 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x1000 PA:0x1000 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x2000 PA:0x2000 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x3000 PA:0x3000 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x4000 PA:0x4000 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x5000 PA:0x5000 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x6000 PA:0x6000 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x7000 PA:0x7000 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x8000 PA:0x8000 size:0x1000 MEM-RO-XN-S
> > [LV3] VA:0x9000 PA:0x9000 size:0x1000 MEM-RO-XN-S
> > [LV3] VA:0xa000 PA:0xa000 size:0x1000 MEM-RO-XN-S
> > [LV3] VA:0xb000 size:0x1000
> > [LV3] (500 invalid descriptors omitted)
> > [LV2] VA:0x200000 size:0x200000
> > [LV2] (30 invalid descriptors omitted)
> > [LV2] VA:0x4000000 size:0x200000
> > ..... <snip>
> >
> > Thanks,
> > Madhukar
> >
>
> --
> Hafnium mailing list
> Hafnium(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/hafnium
>
Quick search indicates mm_vm_dump() and the functions it calls in
src/mm.c should do what you want. i've not tried it or don't know the
format, but this may be what you are looking for.
-Raghu
On 7/16/20 11:03 AM, Madhukar Pappireddy via Hafnium wrote:
> Hi,
>
> I was wondering if there is support in Hafnium to dump page tables to a log file. I am new to the Hafnium project and would appreciate any help. Below is an example from TF-A which provides such provision.
>
> ......<snip>
> VERBOSE: Translation tables state:
> VERBOSE: Xlat regime: EL3
> VERBOSE: Max allowed PA: 0xfffffffff
> VERBOSE: Max allowed VA: 0xfffffffff
> VERBOSE: Max mapped PA: 0x2f1fffff
> VERBOSE: Max mapped VA: 0x2f1fffff
> VERBOSE: Initial lookup level: 1
> VERBOSE: Entries @initial lookup level: 64
> VERBOSE: Used 3 sub-tables out of 5 (spare: 2)
> [LV1] VA:0x0 size:0x40000000
> [LV2] VA:0x0 size:0x200000
> [LV3] VA:0x0 PA:0x0 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x1000 PA:0x1000 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x2000 PA:0x2000 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x3000 PA:0x3000 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x4000 PA:0x4000 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x5000 PA:0x5000 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x6000 PA:0x6000 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x7000 PA:0x7000 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x8000 PA:0x8000 size:0x1000 MEM-RO-XN-S
> [LV3] VA:0x9000 PA:0x9000 size:0x1000 MEM-RO-XN-S
> [LV3] VA:0xa000 PA:0xa000 size:0x1000 MEM-RO-XN-S
> [LV3] VA:0xb000 size:0x1000
> [LV3] (500 invalid descriptors omitted)
> [LV2] VA:0x200000 size:0x200000
> [LV2] (30 invalid descriptors omitted)
> [LV2] VA:0x4000000 size:0x200000
> ..... <snip>
>
> Thanks,
> Madhukar
>
Hi All,
The next TF-A Tech Forum is scheduled for Thu 16th July 2020 16:00 – 17:00 (BST). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know.
Agenda:
* Secure EL2 SPM (Secure Partition Manager) Hafnium-based
* In this TF-A Tech Forum session we present the status and open roadmap for the Secure Partition Manager firmware development. The TF-A SPM is the reference open source implementation for the PSA FF-A (Platform Security Architecture Firmware Framework for A-class) specification in the Secure world. It leverages the Armv8.4-Secure EL2 extension bringing virtualization technology in the Secure world (S-EL2 exception level). The development derives originally from the Google Hafnium project, which has been recently transitioned to https://www.trustedfirmware.org/ under the BSD 3-Clause license.
* Optional TF-A Mailing List Topic Discussions
If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled.
Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/
A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list.
Thanks
Joanna
No, it's only necessary if you're changing a submodule, or have changes
that are in some other way dependent on each other. Most changes don't need
a topic.
On Thu, 9 Jul 2020 at 17:50, Varun Wadekar via Hafnium <
hafnium(a)lists.trustedfirmware.org> wrote:
> Hello,
>
> I think this is a good idea to keep multiple moving parts in sync. OTOH,
> does this also mean that all changes *must* be part of a topic branch? That
> would be an overkill IMO.
>
> -Varun
>
> -----Original Message-----
> From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> On Behalf Of
> Olivier Deprez via Hafnium
> Sent: Thursday, July 9, 2020 6:16 AM
> To: Benjamin Copeland <ben.copeland(a)linaro.org>; Joanna Farley <
> Joanna.Farley(a)arm.com>; bill.fletcher(a)linaro.org
> Cc: hafnium(a)lists.trustedfirmware.org
> Subject: Re: [Hafnium] change.submitWholeTopic option for Gerrit
>
> External email: Use caution opening links or attachments
>
>
> Ben,
>
> Kindly please hold on, I guess I should forward this comm. to other MLs
> for which the corresponding tforg projects will inherit the newly enabled
> feature.
>
> Thanks & Regards,
> Olivier.
>
> ________________________________________
> From: Benjamin Copeland <ben.copeland(a)linaro.org>
> Sent: 09 July 2020 15:12
> To: Joanna Farley; bill.fletcher(a)linaro.org
> Cc: Olivier Deprez; Andrew Walbran; hafnium(a)lists.trustedfirmware.org
> Subject: Re: [Hafnium] change.submitWholeTopic option for Gerrit
>
> If we are all in agreement I will get it enabled.
>
> Regards
>
> Ben
>
> On Thu, 9 Jul 2020 at 13:51, Joanna Farley <Joanna.Farley(a)arm.com<mailto:
> Joanna.Farley(a)arm.com>> wrote:
> Agree __
>
> On 09/07/2020, 13:48, "Hafnium on behalf of Olivier Deprez via Hafnium" <
> hafnium-bounces(a)lists.trustedfirmware.org<mailto:
> hafnium-bounces(a)lists.trustedfirmware.org> on behalf of
> hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>>
> wrote:
>
> Hi Andrew,
>
> We seem to reach a consensus within ARM that it is something we can
> enable.
> As a slight usage detail, we'd expect developers to use their initials
> for gerrit topics such a xy/topic-name.
> That's already recommended for TF-A, although not always enforced.
> This would avoid unintended/accidental merges in different repos
> because of gerrit topic name clashes.
>
> Does it make sense?
>
> Other folks in the ML, please shout if you disagree (you can also
> express that you agree 🙂).
>
> Regards,
> Olivier.
>
>
> ________________________________
> From: Andrew Walbran
> Sent: Wednesday, July 01, 2020 11:28
> To: hafnium(a)lists.trustedfirmware.org<mailto:
> hafnium(a)lists.trustedfirmware.org>; Benjamin Copeland; Olivier Deprez
> Subject: Re: change.submitWholeTopic option for Gerrit
>
> Any thoughts on this?
>
> On Fri, 26 Jun 2020 at 21:21, Andrew Walbran <qwandor(a)google.com
> <mailto:qwandor@google.com><mailto:qwandor@google.com<mailto:
> qwandor(a)google.com>>> wrote:
> Hello,
> How would people feel about enabling the change.submitWholeTopic
> option (
> https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#cha…)
> for Gerrit?
>
> So far, we have relied on this to ensure that submodule changes get
> submitted along with the corresponding change to the main repository. Our
> usual workflow has been that whenever a change is made to one of the
> submodule repositories, both that change and the corresponding change to
> the main repository are tagged with the same topic. That way it is only
> possible to submit either once they have all been reviewed +2 and the main
> change has passed presubmit. This avoids submodules getting out of sync or
> changes to them being missed or not properly tested.
>
> However, it looks like this is a per-host configuration option rather
> than per-repository, so it would also affect the other Trusted Firmware
> projects using the same Gerrit host. Are there any other uses of topics
> there which would conflict with this config change?
>
> (If there are other people who might have an opinion on this please
> add them to the thread.)
> --
> Hafnium mailing list
> Hafnium(a)lists.trustedfirmware.org<mailto:
> Hafnium(a)lists.trustedfirmware.org>
> https://lists.trustedfirmware.org/mailman/listinfo/hafnium
>
> --
> Hafnium mailing list
> Hafnium(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/hafnium
> --
> Hafnium mailing list
> Hafnium(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/hafnium
>
Hello,
I think this is a good idea to keep multiple moving parts in sync. OTOH, does this also mean that all changes *must* be part of a topic branch? That would be an overkill IMO.
-Varun
-----Original Message-----
From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> On Behalf Of Olivier Deprez via Hafnium
Sent: Thursday, July 9, 2020 6:16 AM
To: Benjamin Copeland <ben.copeland(a)linaro.org>; Joanna Farley <Joanna.Farley(a)arm.com>; bill.fletcher(a)linaro.org
Cc: hafnium(a)lists.trustedfirmware.org
Subject: Re: [Hafnium] change.submitWholeTopic option for Gerrit
External email: Use caution opening links or attachments
Ben,
Kindly please hold on, I guess I should forward this comm. to other MLs for which the corresponding tforg projects will inherit the newly enabled feature.
Thanks & Regards,
Olivier.
________________________________________
From: Benjamin Copeland <ben.copeland(a)linaro.org>
Sent: 09 July 2020 15:12
To: Joanna Farley; bill.fletcher(a)linaro.org
Cc: Olivier Deprez; Andrew Walbran; hafnium(a)lists.trustedfirmware.org
Subject: Re: [Hafnium] change.submitWholeTopic option for Gerrit
If we are all in agreement I will get it enabled.
Regards
Ben
On Thu, 9 Jul 2020 at 13:51, Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>> wrote:
Agree __
On 09/07/2020, 13:48, "Hafnium on behalf of Olivier Deprez via Hafnium" <hafnium-bounces(a)lists.trustedfirmware.org<mailto:hafnium-bounces@lists.trustedfirmware.org> on behalf of hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>> wrote:
Hi Andrew,
We seem to reach a consensus within ARM that it is something we can enable.
As a slight usage detail, we'd expect developers to use their initials for gerrit topics such a xy/topic-name.
That's already recommended for TF-A, although not always enforced.
This would avoid unintended/accidental merges in different repos because of gerrit topic name clashes.
Does it make sense?
Other folks in the ML, please shout if you disagree (you can also express that you agree 🙂).
Regards,
Olivier.
________________________________
From: Andrew Walbran
Sent: Wednesday, July 01, 2020 11:28
To: hafnium(a)lists.trustedfirmware.org<mailto:hafnium@lists.trustedfirmware.org>; Benjamin Copeland; Olivier Deprez
Subject: Re: change.submitWholeTopic option for Gerrit
Any thoughts on this?
On Fri, 26 Jun 2020 at 21:21, Andrew Walbran <qwandor(a)google.com<mailto:qwandor@google.com><mailto:qwandor@google.com<mailto:qwandor@google.com>>> wrote:
Hello,
How would people feel about enabling the change.submitWholeTopic option (https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#cha…) for Gerrit?
So far, we have relied on this to ensure that submodule changes get submitted along with the corresponding change to the main repository. Our usual workflow has been that whenever a change is made to one of the submodule repositories, both that change and the corresponding change to the main repository are tagged with the same topic. That way it is only possible to submit either once they have all been reviewed +2 and the main change has passed presubmit. This avoids submodules getting out of sync or changes to them being missed or not properly tested.
However, it looks like this is a per-host configuration option rather than per-repository, so it would also affect the other Trusted Firmware projects using the same Gerrit host. Are there any other uses of topics there which would conflict with this config change?
(If there are other people who might have an opinion on this please add them to the thread.)
--
Hafnium mailing list
Hafnium(a)lists.trustedfirmware.org<mailto:Hafnium@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/hafnium
--
Hafnium mailing list
Hafnium(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/hafnium
