- Linaro-open-discussions - op-lists.linaro.org

Linaro OP-TEE Contribution (LOC) monthly meeting February 28

by Jens Wiklander

Hi, It's soon time for another LOC monthly meeting. For time and connection details see the calendar at https://www.trustedfirmware.org/meetings/ I have recently seen interest in OP-TEE and S-EL2. As you may know, we have a working setup with OP-TEE and Hafnium with most of the needed patches upstream. Any other topics? Thanks, Jens

2 years, 3 months

2
1
0 0

[RFC PATCH 1/1] qemu_v8: add changes to run 2 SPs

by shiju.jose＠huawei.com

From: Shiju Jose <shiju.jose(a)huawei.com> Add changes to run 2 SPs at S-EL1 for SPMC_AT_EL=2, where Hafnium is loaded at S-EL2. This is an experimental version to test loading and booting of more than one SP. Notes and Observations: 1. Secondary SP is built from the optee-os code with different CFG_TZDRAM parameters. 2. optee-os to be build after building the secondary-optee-os, otherwise getting Stage-2 page fault when booting the primary SP. 3. When build together with optee-os the secondary-optee-os is build only when the corresponding target(secondary-optee-os-common) in the common.mk is used. Signed-off-by: Shiju Jose <shiju.jose(a)huawei.com> --- common.mk | 7 ++++ qemu_v8.mk | 36 ++++++++++++++++--- qemu_v8/secondary_optee_sp_manifest.dts | 46 +++++++++++++++++++++++++ qemu_v8/sp_layout.json | 4 +++ qemu_v8/spmc_el2_manifest.dts | 10 +++++- qemu_v8/tb_fw_config.dts | 4 +++ 6 files changed, 102 insertions(+), 5 deletions(-) create mode 100644 qemu_v8/secondary_optee_sp_manifest.dts diff --git a/common.mk b/common.mk index e5f2333..1de5426 100644 --- a/common.mk +++ b/common.mk @@ -542,6 +542,13 @@ optee-os-common: optee-os-clean-common: $(MAKE) -C $(OPTEE_OS_PATH) $(OPTEE_OS_COMMON_FLAGS) clean +.PHONY: secondary-optee-os-common +secondary-optee-os-common: + $(MAKE) -C $(OPTEE_OS_PATH) $(OPTEE_OS_COMMON_FLAGS) + +.PHONY: secondary-optee-os-clean-common +secondary-optee-os-clean-common: + $(MAKE) -C $(OPTEE_OS_PATH) $(OPTEE_OS_COMMON_FLAGS) clean ################################################################################ # OP-TEE Rust ################################################################################ diff --git a/qemu_v8.mk b/qemu_v8.mk index d6bf9a7..20b5b8b 100644 --- a/qemu_v8.mk +++ b/qemu_v8.mk @@ -100,7 +100,7 @@ ROOTFS_ENTRY ?= 0x44000000 ROOTFS_LOADADDR ?= 0x44000000 ifeq ($(SPMC_AT_EL),2) -BL32_DEPS ?= hafnium optee-os +BL32_DEPS ?= hafnium secondary-optee-os optee-os else BL32_DEPS ?= optee-os endif @@ -130,7 +130,7 @@ endif # Targets ################################################################################ TARGET_DEPS := arm-tf buildroot linux optee-os qemu -TARGET_CLEAN := arm-tf-clean buildroot-clean linux-clean optee-os-clean \ +TARGET_CLEAN := arm-tf-clean buildroot-clean linux-clean optee-os-clean secondary-optee-os-clean \ qemu-clean check-clean TARGET_DEPS += $(BL33_DEPS) @@ -246,6 +246,7 @@ endif rm -f $(BINARIES_PATH)/bl32_extra2.bin rm -f $(BINARIES_PATH)/tos_fw_config.dtb rm -f $(BINARIES_PATH)/op-tee.pkg + rm -f $(BINARIES_PATH)/sec-op-tee.pkg ifeq ($(SPMC_AT_EL),1) ln -sf $(TF_A_OUT)/fdts/spmc_el1_manifest.dtb \ $(BINARIES_PATH)/tos_fw_config.dtb @@ -259,6 +260,7 @@ else ifeq ($(SPMC_AT_EL),2) $(BINARIES_PATH)/tb_fw_config.dtb ln -sf $(HAFNIUM_BIN) $(BINARIES_PATH)/bl32.bin ln -sf $(TF_A_OUT)/op-tee.pkg $(BINARIES_PATH)/op-tee.pkg + ln -sf $(TF_A_OUT)/sec-op-tee.pkg $(BINARIES_PATH)/sec-op-tee.pkg else ifeq ($(SPMC_AT_EL),3) ln -sf $(TF_A_OUT)/fdts/spmc_el3_manifest.dtb \ $(BINARIES_PATH)/tos_fw_config.dtb @@ -373,13 +375,17 @@ OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_2 = CFG_CORE_SEL2_SPMC=y OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_2 += CFG_ARM_GICV3=n CFG_CORE_HAFNIUM_INTC=y # [0e00.0000 0e2f.ffff] is reserved to early boot and SPMC # [0e30.0000 0e33.ffff] is reserved manifest etc (op-tee.pkg) -OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_2 += CFG_TZDRAM_START=0x0e304000 -OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_2 += CFG_TZDRAM_SIZE=0x00cfc000 OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_2 += CFG_CORE_WORKAROUND_NSITR_CACHE_PRIME=n OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_3 = CFG_CORE_EL3_SPMC=y OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_3 += CFG_DT_ADDR=0x40000000 OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_3 += CFG_CORE_RESERVED_SHM=n +OPTEE_OS_TZDRAM_FLAGS_SPMC_AT_EL_2 = CFG_TZDRAM_START=0x0e304000 +OPTEE_OS_TZDRAM_FLAGS_SPMC_AT_EL_2 += CFG_TZDRAM_SIZE=0x006fc000 + +SECONDARY_OPTEE_OS_TZDRAM_FLAGS_SPMC_AT_EL_2 = CFG_TZDRAM_START=0x0ea04000 +SECONDARY_OPTEE_OS_TZDRAM_FLAGS_SPMC_AT_EL_2 += CFG_TZDRAM_SIZE=0x005fc000 + ifeq ($(XEN_BOOT),y) OPTEE_OS_COMMON_FLAGS += CFG_VIRTUALIZATION=y endif @@ -394,10 +400,32 @@ endif OPTEE_OS_COMMON_FLAGS += $(OPTEE_OS_COMMON_FLAGS_SPMC_AT_EL_$(SPMC_AT_EL)) +OP_TEE_OS_PATH ?= $(ROOT)/optee_os +OP_TEE_OS_BIN ?= $(OP_TEE_OS_PATH)/out/arm/core/tee-pager_v2.bin +SECONDARY_OP_TEE_OS_BIN ?= $(OP_TEE_OS_PATH)/out/arm/core/secondary-tee-pager_v2.bin + +.PHONY: optee-os +optee-os: optee-os-clean-common +optee-os: OPTEE_OS_COMMON_FLAGS := $(OPTEE_OS_COMMON_FLAGS) $(OPTEE_OS_TZDRAM_FLAGS_SPMC_AT_EL_$(SPMC_AT_EL)) optee-os: optee-os-common +################################################################################ +# secondary optee-os +################################################################################ + +.PHONY: secondary-optee-os +secondary-optee-os: secondary-optee-os-clean-common +secondary-optee-os: OPTEE_OS_COMMON_FLAGS := $(OPTEE_OS_COMMON_FLAGS) $(SECONDARY_OPTEE_OS_TZDRAM_FLAGS_SPMC_AT_EL_$(SPMC_AT_EL)) +secondary-optee-os: secondary-optee-os-common +secondary-optee-os: + cp $(OP_TEE_OS_BIN) $(SECONDARY_OP_TEE_OS_BIN) + +.PHONY: optee-os-clean optee-os-clean: optee-os-clean-common +.PHONY: secondary-optee-os-clean +secondary-optee-os-clean: rm $(SECONDARY_OPTEE_OS_BIN) + ################################################################################ # Hafnium ################################################################################ diff --git a/qemu_v8/secondary_optee_sp_manifest.dts b/qemu_v8/secondary_optee_sp_manifest.dts new file mode 100644 index 0000000..0002351 --- /dev/null +++ b/qemu_v8/secondary_optee_sp_manifest.dts @@ -0,0 +1,46 @@ +/* + * Copyright (c) 2020, Arm Limited. All rights reserved. + * Copyright (c) 2022, Linaro Limited + * + * SPDX-License-Identifier: BSD-3-Clause + * + * This file is a Partition Manifest (PM) for a minimal Secure Partition (SP) + * that has additional optional properties defined. + * + */ + +/dts-v1/; + +/ { + compatible = "arm,ffa-manifest-1.0"; + + /* Properties */ + description = "sec-op-tee"; + ffa-version = <0x00010001>; /* 31:16 - Major, 15:0 - Minor */ + uuid = <0xe4b5f42f 0xed112faf 0x3351d7b9 0xe9cc99fc>; + id = <1>; + execution-ctx-count = <8>; + exception-level = <2>; /* S-EL1 */ + execution-state = <0>; /* AARCH64 */ + load-address = <0xea00000>; + entrypoint-offset = <0x4000>; + xlat-granule = <0>; /* 4KiB */ + boot-order = <0>; + messaging-method = <0x3>; /* Direct messaging only */ + ns-interrupts-action = <1>; /* NS_ACTION_ME */ + + /* Boot protocol */ + gp-register-num = <0x0>; + + device-regions { + compatible = "arm,ffa-manifest-device-regions"; + + uart1 { + base-address = <0x00000000 0x09040000>; + pages-count = <1>; + attributes = <0x3>; /* read-write */ + /* SPI, level-triggered, secure, priority=1 */ + interrupts = <0x28 0xb01>; + }; + }; +}; diff --git a/qemu_v8/sp_layout.json b/qemu_v8/sp_layout.json index c6a02a9..2f9e5b9 100644 --- a/qemu_v8/sp_layout.json +++ b/qemu_v8/sp_layout.json @@ -2,5 +2,9 @@ "op-tee" : { "image": "../../optee_os/out/arm/core/tee-pager_v2.bin", "pm": "optee_sp_manifest.dts" + }, + "sec-op-tee" : { + "image": "../../optee_os/out/arm/core/secondary-tee-pager_v2.bin", + "pm": "secondary_optee_sp_manifest.dts" } } diff --git a/qemu_v8/spmc_el2_manifest.dts b/qemu_v8/spmc_el2_manifest.dts index 7acaa38..4e73df1 100644 --- a/qemu_v8/spmc_el2_manifest.dts +++ b/qemu_v8/spmc_el2_manifest.dts @@ -30,7 +30,15 @@ load_address = <0xe300000>; debug_name = "op-tee"; vcpu_count = <4>; - mem_size = <0xd00000>; + mem_size = <0x700000>; + }; + + vm2 { + is_ffa_partition; + load_address = <0xea00000>; + debug_name = "sec-op-tee"; + vcpu_count = <4>; + mem_size = <0x600000>; }; }; diff --git a/qemu_v8/tb_fw_config.dts b/qemu_v8/tb_fw_config.dts index 68f7b3b..ce3c26a 100644 --- a/qemu_v8/tb_fw_config.dts +++ b/qemu_v8/tb_fw_config.dts @@ -14,5 +14,9 @@ uuid = "486178e0-e7f8-11e3-bc5e-0002a5d5c51b"; load-address = <0xe300000>; }; + sec-op-tee { + uuid = "2ff4b5e4-af2f-11ed-b9d7-5133fc99cce9"; + load-address = <0xea00000>; + }; }; }; -- 2.25.1

2 years, 4 months

3
2
0 0

Qemu TCG support for virtual-cpuhotplug/online-policy

by James Morse

Hi Miguel got in touch with a suggested fix for the Qemu TCG support for virtual-cpuhotplug/online-policy. I recall we talked about this last week, and didn't intend to support TCG. It didn't work for me on x86 when I tried it, Jonathan suggested we don't know what its needed for. Miguel - over to you! Thanks, James

2 years, 4 months

2
1
0 0

About the test_bit() check in the kvm_hvc_user() part of hypercall.c

by Salil Mehta

Hi james, Below is the check [1] I was referring to in today's LOD call and it looks you have already fixed it in your latest patches [2] posted > > [2] https://git.gitlab.arm.com/linux-arm/linux-jm.git virtual_cpu_hotplug/rfc/v0.2 > > > > #Hunk > > > > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c > > index fcab358de228..3c2136cd7a3f 100644 > > --- a/arch/arm64/kvm/hypercalls.c > > +++ b/arch/arm64/kvm/hypercalls.c > > @@ -126,7 +126,7 @@ int kvm_hvc_user(struct kvm_vcpu *vcpu) > > int i; > > struct kvm_run *run = vcpu->run; > > > > - if (test_bit(KVM_ARCH_FLAG_HVC_TO_USER, &vcpu->kvm->arch.flags)) { > > + if (!test_bit(KVM_ARCH_FLAG_HVC_TO_USER, &vcpu->kvm->arch.flags)) { > > smccc_set_retval(vcpu, SMCCC_RET_NOT_SUPPORTED, 0, 0, 0); > > return 1; > > } > > Makes sense - thanks! I couldn't test this without the Qemu changes. > [1] https://op-lists.linaro.org/archives/list/linaro-open-discussions@op-lists.… [2] https://lore.kernel.org/linux-arm-kernel/20230203135043.409192-30-james.mor…

2 years, 4 months

1
0
0 0

[RFC PATCH 1/2] arm_mpam/resctrl: Skip online/offline a CPU if not part of a class' affinity

by Hesham Almatary

If a CPU isn't part of the class' affinity, skip onlining it. Otherwise, it will try to allocate a domain for it that will fault. An example is when there are 2 memory MSCs with affinities to the first 64 CPUs (32 CPUs for each memory MSC) and 1 L3 cache MSC with affinity to the first 32 CPUs. When a call back to online CPU 63 for the second memory MSC is triggered, the function will first check the caches, and it will fault and return as CPU 63 is not part of the caches' affinity, without trying to check for the memory MSC. Thus, only 1 memory MSC will show up, even though there are 2 that could be managed. Also skip when offlining a CPU that's not part of the class' affinity. Signed-off-by: Hesham Almatary <hesham.almatary(a)huawei.com> --- drivers/platform/mpam/mpam_resctrl.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/platform/mpam/mpam_resctrl.c b/drivers/platform/mpam/mpam_resctrl.c index 471fb1a6c7e2..bfc25a8e4f03 100644 --- a/drivers/platform/mpam/mpam_resctrl.c +++ b/drivers/platform/mpam/mpam_resctrl.c @@ -1076,6 +1076,9 @@ int mpam_resctrl_online_cpu(unsigned int cpu) if (!res->class) continue; // dummy_resource; + if (!cpumask_test_cpu(cpu, &res->class->affinity)) + continue; // This CPU isn't part of the class' affinity; + dom = mpam_get_domain_from_cpu(cpu, res); if (dom) { cpumask_set_cpu(cpu, &dom->resctrl_dom.cpu_mask); @@ -1108,6 +1111,9 @@ int mpam_resctrl_offline_cpu(unsigned int cpu) if (!res->class) continue; // dummy resource + if (!cpumask_test_cpu(cpu, &res->class->affinity)) + continue; // This CPU isn't part of the class' affinity; + d = resctrl_get_domain_from_cpu(cpu, &res->resctrl_res); dom = container_of(d, struct mpam_resctrl_dom, resctrl_dom); -- 2.25.1

2 years, 4 months

1
2
0 0

Invitation: OpenEuler / Bigtop discussion @ Wed Feb 1, 2023 10am - 10:50am (CST) (linaro-open-discussions@op-lists.linaro.org)

by guodong.xu＠linaro.org

OpenEuler / Bigtop discussion Wednesday Feb 1, 2023 ⋅ 10am – 10:50am China Standard Time - Shanghai Location https://linaro-org.zoom.us/j/99098081330 https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9909808… Hi, AllI would like to call a meeting to discuss our progress in OpenEuler / Bigtop enablement. You are welcomed to dial in. As a topic, we proposed the following text as a presentation to the bigtop's dev-maillist. Please help review. Your comments of any kind are highly appreciated.==1. IntroductionOpenEuler is an innovative open source OS platform built on kernel innovations and a solid cloud base to cover all scenarios.(1) The OpenEuler operating system has coverd mainstream technical architectures, including ARM/X86/RISC-V/NPU/GPU/DPU etc.(2) All scenarios application support and development tool chain.More information can be found on the official website: https://www.openeuler.org/en/More and more manufacturers use OpenEuler OS, so we are ready to support OpenEuler OS for Bigtop.2. Related work(1) Support the build of puppet and slaves docker, the base docker can pull from the OpenEuler web.PR address: https://github.com/apache/bigtop/pull/1051Issue address: https://issues.apache.org/jira/browse/BIGTOP-3873(2) All components has compiled.(Bigtop master branch, ARM/X86)(3) All components smoke test passed，except ambari component(fix the problem to support python3).(4) JIRA: BIGTOP-3875 introduced the adaptation work content, including 11 sub JIRAs.https://issues.apache.org/jira/browse/BIGTOP-38753. Next(1) A discussion on introducing Bigtop into OpenEuler community has been initiated, as a community maintainer of openEuler Bigdata SIG.(2) We will support and maintain the openEuler version for a long time.==──────────Guodong Xu is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://linaro-org.zoom.us/j/99098081330Meeting ID: 990 9808 1330One tap mobile+16694449171,,99098081330# US+16699009128,,99098081330# US (San Jose)Dial by your location +1 669 444 9171 US +1 669 900 9128 US (San Jose) +1 346 248 7799 US (Houston) +1 719 359 4580 US +1 253 205 0468 US +1 253 215 8782 US (Tacoma) +1 386 347 5053 US +1 507 473 4847 US +1 564 217 2000 US +1 646 558 8656 US (New York) +1 646 931 3860 US +1 689 278 1000 US +1 301 715 8592 US (Washington DC) +1 305 224 1968 US +1 309 205 3325 US +1 312 626 6799 US (Chicago) +1 360 209 5623 US 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 990 9808 1330Find your local number: https://linaro-org.zoom.us/u/adCzz3i18X────────── Organizer guodong.xu(a)linaro.org guodong.xu(a)linaro.org Guests guodong.xu(a)linaro.org - organizer linaro-open-discussions(a)op-lists.linaro.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=MWY5YW40bmYwN2E0… Reply for linaro-open-discussions(a)op-lists.linaro.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=MWY5YW40bmYwN2E0… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 4 months

2
1
0 0

Invitation: Linaro Open Discussions monthly meeting @ Fri 3 Feb 2023 22:00 - 23:00 (HKT) (linaro-open-discussions@op-lists.linaro.org)

by joyce.qi＠linaro.org

Linaro Open Discussions monthly meeting Friday 3 Feb 2023 ⋅ 22:00 – 23:00 Hong Kong Standard Time Location https://linaro-org.zoom.us/j/95682500341 https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9568250… Joyce QI 邀请您参加预先安排的 Zoom 会议。加入 Zoom 会议 https://linaro-org.zoom.us/j/95682500341 会议号：956 8250 0341 手机一键拨号 +16699009128,,95682500341# 美国 (San Jose) +13462487799,,95682500341# 美国 (Houston) 根据您的位置拨号 +1 669 900 9128 美国 (San Jose) +1 346 248 7799 美国 (Houston) +1 253 215 8782 美国 (Tacoma) +1 646 558 8656 美国 (New York) +1 301 715 8592 美国 (Washington DC) +1 312 626 6799 美国 (Chicago) 888 788 0099 美国免费 877 853 5247 美国免费会议号：956 8250 0341 查找本地号码：https://linaro-org.zoom.us/u/ady2J9Zn7t Organiser joyce.qi(a)linaro.org joyce.qi(a)linaro.org Guests joyce.qi(a)linaro.org- organiser Mike Holmes jonathan.cameron(a)huawei.com lorenzo.pieralisi(a)arm.com james.morse(a)arm.com shameerali.kolothum.thodi(a)huawei.com linaro-open-discussions(a)op-lists.linaro.org linux(a)armlinux.org.uk View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=cmlrbjNnOTdlODdu… Reply for linaro-open-discussions(a)op-lists.linaro.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=cmlrbjNnOTdlODdu… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee of the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organiser, be added to the guest list, invite others regardless of their own invitation status or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 4 months

1
0
0 0

Re: Linaro-open-discussions Digest, Vol 28, Issue 3

by Joyce Qi

Hi all, Any topics needs to be discussed on next Tuesday? Thanks:) Joyce > 在 2023年1月17日，上午8:00，linaro-open-discussions-request@op-lists.linaro.org 写道： > > Send Linaro-open-discussions mailing list submissions to > linaro-open-discussions(a)op-lists.linaro.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > linaro-open-discussions-request(a)op-lists.linaro.org > > You can reach the person managing the list at > linaro-open-discussions-owner(a)op-lists.linaro.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Linaro-open-discussions digest..." > > Today's Topics: > > 1. Re: [RFC PATCH 2/2] MPAM/resctrl: allocate a domain per component > (Hesham Almatary) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 16 Jan 2023 11:31:06 +0000 > From: Hesham Almatary <hesham.almatary(a)huawei.com> > Subject: [Linaro-open-discussions] Re: [RFC PATCH 2/2] MPAM/resctrl: > allocate a domain per component > To: James Morse <james.morse(a)arm.com> > Cc: linaro-open-discussions(a)op-lists.linaro.org, linuxarm(a)huawei.com > Message-ID: <20230116113106.00001a2d(a)huawei.com> > Content-Type: text/plain; charset="US-ASCII" > > Hello James, > > Many thanks for clarifying things up, that definitely helps with my > understanding. > > On Thu, 12 Jan 2023 13:38:17 +0000 > James Morse <james.morse(a)arm.com> wrote: > >> Hi Hesham, >> >> On 12/01/2023 10:34, Hesham Almatary wrote: >>> Thanks for getting back to me on this. I have done some changes to >>> my ACPI tables and got your code working fine without this patch. In >>> particular, I matched the proximity domain field with the NUMA node >>> ID for each memory controller. If they differ, the code won't work >>> (as it has the assumption that the proximity domain is the same as >>> NUMA id, >> >> Right, if there is an extra level of indirection in there, its >> something I wasn't aware of. I'll need to dig into it. I agree this >> explains what you were seeing. >> >> >>> from which the affinity/accessibility is set). This leaves me with a >>> few questions regarding the design and implementation of the driver. >>> I'd appreciate your input on that. >> >>> 1) What does a memory MSC correspond to? A class (with a unique ID) >>> or a component? From the code, it seems like it maps to a component >>> to me. >> >> An MSC is the device, it has registers and generates interrupts. If >> its part of your memory controller, it gets described like that in >> the ACPI tables, which lets linux guess that this MSC (or the RIS >> within it) control some policy in the memory controller. >> >> Components exist to group devices that should be configured the same. >> This happens where designs are sliced up, but this slicing makes no >> sense to the software. Classes are a group of components that do the >> same thing, but not to the same resource. e.g. they control memory >> controllers. >> >> The ACPI tables should describe the MSC, its up to the driver to >> build the class and component structures from what it can infer from >> the other ACPI tables. >> >> >>> 2) Could we have a use case in which we have different class IDs >>> with the same class type? If yes could you please give an example? >> >> Your L2 and L3 are both caches, but use the level number as the id. >> I doubt anyone builds a system with MSC on both, but its possible by >> the architecture, and we could expose both via resctrl. >> >> >>> 3) What should a component ID for a memory MSC be/represent? The >>> code assumes it's a (NUMA?) node ID. >> >> The component-ids are some number that makes sense to linux, and >> matches something in the ACPI tables. These are exposed via the >> schema file to user-space. For the caches, its the cache-id property >> from the PPTT table. This is exposed to user-space via >> /sys/devices/system/cpu/cpu0/cache/index3/id or equivalent. >> >> Its important that user-space can work out which CPUs share a >> component/domain in the schema. Using a sensible id is the >> pre-requisite for that. >> >> Intel's memory bandwidth control appears to be implemented on the L3, >> so they re-use the id of the L3 cache. These seem to correspond to >> NUMA nodes already. >> >> For MPAM - we have no idea if the memory controllers map 1:1 with any >> level in the cache. Instead, the driver expects to use the numa node >> number directly. >> >> (I'll put this on the list of KNOWN_ISSUES, the Intel side of this >> ought to be cleaned up so it doesn't break if they build a SoC where >> L3 doesn't map 1:1 with Numa nodes. It looks like they are getting >> away with it because Atom doesn't support L3 or memory bandwidth) >> > That's very useful and informative. Some form of documentation (in > KNOWN_ISSUES, comments, or a README) would be quite useful for such > assumptions as the ACPI/MPAM spec doesn't mention that (i.e., the > logical ID assignments from OS point of view). > >> >>> 4) What should a class ID represent for a memory MSC? Which is >>> different from the class type itself. >> >> The class id is private to the driver, for the caches it needs to be >> the cache level. Because of that memory is shoved at the end, on the >> assumption no-one has an L255 cache, and 'unknown' devices are shoved >> at the beginning... L0 caches probably do exist, but I doubt anyone >> would add an MSC to them. >> >> Classes can't be arbitrarily created, as the resctrl picking code >> needs to know how they map to resctrl schemas, as we can't invent new >> schemas without messing up user-space. >> >> >>> 5) How would 4 memory MSCs (with different proximity domains) map to >>> classes and components? >> >> Each MSC would be a device. There would be one device per component, >> because each proximity domain is different. They would all be the >> same class, as you'd described them all with a memory type in the >> ACPI tables. >> >> If you see a problem with this, let me know! The folk who write the >> ACPI specs didn't find any systems where this would lead to >> problems... that doesn't mean you haven't build something that looks >> quite different. >> >> >>> 6) How would 2 Memory MSCs with(in) the same proximity domain and/or >>> same NUMA node work, if at all? >> >> If you build this, I bet your hardware people say those two MSC must >> be programmed the same for the regulation to work. (if not - how is >> software expected to understand the hashing scheme used to map >> physical-addresses to memory controllers?!) >> >> Each MSC would be a device. They would both be part of the same >> component as they have the same proximity domain. >> >> Configuration is applied to the component, so each device/MSC within >> the component is always configured the same. >> >> >>> 7) Should the ACPI/MPAM MSC's "identifier" field be mapped to class >>> IDs or component IDs at all? >> >> Classes, no - these are just for the driver to keep track of the >> groups. Components, probably ... but another number may make more >> sense. This should line up with something that is already exposed to >> user-space via sysfs. >> >> >> >> Thanks, >> >> James >> >> > > > ------------------------------ > > Subject: Digest Footer > > Linaro-open-discussions mailing list -- linaro-open-discussions(a)op-lists.linaro.org > To unsubscribe send an email to linaro-open-discussions-leave(a)op-lists.linaro.org > > > ------------------------------ > > End of Linaro-open-discussions Digest, Vol 28, Issue 3 > ******************************************************

2 years, 4 months

5
6
0 0

Linaro OP-TEE Contribution (LOC) monthly meeting January 24

by Jens Wiklander

Hi, It's soon time for another LOC monthly meeting. For time and connection details see the calendar at https://www.trustedfirmware.org/meetings/ I have one topic to discuss: OP-TEE 3.20.0 is just released and a PR [1] to upgrade from TEE Internal Core API version 1.1 to 1.3.1 is soon to be merged. This may bump the major OP-TEE version in the next release. There's in particular the define TEE_ALG_SM2_PKE which is tricky to keep compatible when upgrading. We have some time until the next release to determine if this is reason enough to bump the major version. Any other topics? [1] https://github.com/OP-TEE/optee_os/pull/5688 Thanks, Jens

2 years, 5 months

1
0
0 0

[RFC PATCH 0/2] Potential minor issues found with Arm's MPAM support

by Hesham Almatary

Potential issues (and fixes to them) for the current MPAM supprot by Arm [1]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git/log/?h=mpam… Hesham Almatary (2): MPAM: Fix calculating the bandwidth granularity MPAM/resctrl: allocate a domain per component drivers/platform/mpam/mpam_resctrl.c | 30 +++++++++++++--------------- 1 file changed, 14 insertions(+), 16 deletions(-) -- 2.33.0

2 years, 5 months

2
11
0 0

2025

2024

2023

2022

2021

2020

Linaro-open-discussions