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

Linaro OP-TEE Contribution, LOC, monthly meeting February 27

by Jens Wiklander

Hi, Tomorrow, Tuesday, February 27 it's time for another LOC monthly meeting. For time and connection details see the calendar at https://www.trustedfirmware.org/meetings/ Moving the RPMB part of tee-supplicant processing into the kernel is making progress. The last patchset [1] got some constructive feedback and I'm preparing a new version based on that. [1] https://lore.kernel.org/lkml/20240131174347.510961-1-jens.wiklander@linaro.… Any other topics? Thanks, Jens

9 months, 4 weeks

1
0
0 0

Invitation to Big Data Technology Discussion Meeting

by Guodong Xu

Dear Linaro-Open-Discussions subscribers, You are cordially invited to a focused meeting on the advancements and future directions in Big Data technology. We aim to bring together experts and enthusiasts for an open discussion on any proposed topics within the realm of Big Data. Event invitation link: https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=MXU3MXBnZX… Date: Feb 27, 2024 Time: 10:00am ~11:00am Timezone: (GMT+08:00) China Standard Time - Shanghai Guodong Xu is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://linaro-org.zoom.us/j/97426775175?pwd=UCtsUTFoZzZDMzRqb1d0ZDE1ZHlEUT… Meeting ID: 974 2677 5175 Passcode: 183020 Thank you. Best Regards, Guodong Xu

10 months

1
0
0 0

Linaro OP-TEE Contribution, LOC, monthly meeting January 25

by Jens Wiklander

Hi, Tomorrow, Tuesday, January 25 it's time for another LOC monthly meeting. For time and connection details see the calendar at https://www.trustedfirmware.org/meetings/ - OP-TEE 4.1.0 has been released - There's an ongoing effort to move tee-supplicant processing into the kernel to avoid user space dependency during boot Any other topics? Thanks, Jens

11 months

1
0
0 0

Invitation: Bigtop / openEuler Sync-up @ Thu Jan 4, 2024 10am - 10:40am (CST) (linaro-open-discussions@op-lists.linaro.org)

by Guodong Xu

Bigtop / openEuler Sync-up Thursday Jan 4, 2024 ⋅ 10am – 10:40am China Standard Time - Shanghai Location https://linaro-org.zoom.us/j/97370571743?pwd=MktwbkdDUUNYaEJUbGNlVjZqeE42Zz… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9737057… Hi, AllI would like to invite everyone to an open discussion to synchronize our progress on supporting openEuler within Bigtop. All who are interested in this area are warmly welcomed to join.openEuler openEuler is an open source, free Linux distribution platform. https://www.openeuler.org/en/Bigtop is an Apache Foundation project for Infrastructure Engineers and Data Scientists looking for comprehensive packaging, testing, and configuration of the leading open source big data components. Bigtop supports a wide range of components/projects, including, but not limited to, Hadoop, HBase and Spark. https://bigtop.apache.org/Best regards,Guodong Xu──────────Guodong Xu is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://linaro-org.zoom.us/j/97370571743?pwd=MktwbkdDUUNYaEJUbGNlVjZqeE42Zz09Meeting ID: 973 7057 1743Passcode: 433476---One tap mobile+13092053325,,97370571743# US+13126266799,,97370571743# US (Chicago)---Dial by your location• +1 309 205 3325 US• +1 312 626 6799 US (Chicago)• +1 346 248 7799 US (Houston)• +1 360 209 5623 US• +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 669 444 9171 US• +1 669 900 9128 US (San Jose)• +1 689 278 1000 US• +1 719 359 4580 US• +1 253 205 0468 US• +1 253 215 8782 US (Tacoma)• +1 301 715 8592 US (Washington DC)• +1 305 224 1968 US• 833 928 4609 US Toll-free• 833 928 4610 US Toll-free• 877 853 5247 US Toll-free• 888 788 0099 US Toll-free• 833 548 0276 US Toll-free• 833 548 0282 US Toll-free• 833 928 4608 US Toll-freeMeeting ID: 973 7057 1743Find your local number: https://linaro-org.zoom.us/u/adsFDXlqEq────────── Organizer Guodong Xu guodong.xu(a)linaro.org Guests Guodong Xu - organizer linaro-open-discussions(a)op-lists.linaro.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWNrMmxxNHZwNm1l… Reply for linaro-open-discussions(a)op-lists.linaro.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWNrMmxxNHZwNm1l… 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

11 months, 3 weeks

1
0
0 0

[Request] Regarding non-RFC patch-set of Virtual CPU Hotplug kernel support

by Salil Mehta

Hi James, Do we have any plan when we want to push the non-RFC Virtual CPU Hotplug patch-set for the kernel side to the community. I guess people will be more interested in reviewing if it is floated with a non-RFC tag. If time is a problem at your side then do you need my help in carrying it forward for you? Please let me know Thanks Salil.

1 year

5
49
0 0

Linaro OP-TEE Contribution, LOC, monthly meeting November 28

by Jens Wiklander

Hi, On Tuesday, November 28 it's time for another LOC monthly meeting. For time and connection details see the calendar at https://www.trustedfirmware.org/meetings/ There's an ongoing effort to add RPMB emulation in QEMU. This should allow RPMB testing in our CI. Any other topics? Thanks, Jens

1 year

1
0
0 0

Recall: Re: [Request] Regarding non-RFC patch-set of Virtual CPU Hotplug kernel support

by Jianyong Wu

Jianyong Wu would like to recall the message, "[Linaro-open-discussions] Re: [Request] Regarding non-RFC patch-set of Virtual CPU Hotplug kernel support". IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

1 year, 1 month

1
0
0 0

[Question] System suspend/resume functionality on ARM64 VM does seem to be working?

by Salil Mehta

Hello, We have been trying to verify the "system suspend/Restore" with vCPU Hotplug patches recently and found this functionality does not work on ARM64 with VMs even without our patches i.e. using latest kernel and qemu repository. estuary:/$ cat /sys/power/mem_sleep [s2idle] estuary:/$ estuary:/$ cat /sys/power/state freeze mem disk estuary:/$ estuary:/$ estuary:/$ echo mem > /sys/power/state [ 60.458445] PM: suspend entry (s2idle) [ 60.458840] Filesystems sync: 0.000 seconds [ 60.459649] Freezing user space processes [ 60.461149] Freezing user space processes completed (elapsed 0.001 seconds) [ 60.461830] OOM killer disabled. [ 60.462144] Freezing remaining freezable tasks [ 60.463188] Freezing remaining freezable tasks completed (elapsed 0.000 seconds) [ 60.463920] printk: Suspending console(s) (use no_console_suspend to debug) (qemu) (qemu) sys system_powerdown system_reset system_wakeup (qemu) system_wakeup Error: wake-up from suspend is not supported by this guest (qemu) Or using # systemctl suspend What is the expected behavior or are we missing something? Thanks Salil

1 year, 1 month

4
7
0 0

Linaro OP-TEE Contribution, LOC, monthly meeting October 24

by Jens Wiklander

Hi, On Tuesday, October 24 it's time for another LOC monthly meeting. For time and connection details see the calendar at https://www.trustedfirmware.org/meetings/ I'm pleased to report that OP-TEE version 4.0.0 has been released [1]. Shyam is trying to get support for handling RPMB driver support within the kernel without a detour via tee-supplicant [2]. This is something we've talking about within the OP-TEE project too. Any other topics? Thanks, Jens [1] https://lists.trustedfirmware.org/archives/list/op-tee@lists.trustedfirmwar… [2] https://github.com/OP-TEE/optee_os/issues/6389

1 year, 1 month

1
0
0 0

aarch64: KVM + GPU: hypervisor encountered an error while trying to access memory

by Guodong Xu

Hi，all May I, representing our members, bring forth an issue for discussion? The impact of this issue is big: Without resolving this issue, the scenario where the GPU is passed through to the virtual machine cannot be used. And it exists on Arm only, x86 is good. (I know workarounds exist, but we want to fix that in the mainline). After reading through so many community emails (see below), I believe it’s unlikely that a single patch can quickly gain everyone's support. A broad discussion involving the ARM ecosystem and the KVM community is essential. Only with consensus can a submitted patch receive sufficient support, eventually resolving this issue in the mainline version. History: - This issue was first submitted to the public on 2021-07-01, refer to this [URL] ( https://gitee.com/openeuler/kernel/issues/I3YRDP?from=project-issue ). - A patch was submitted to the kernel maillist on 2022-04-01, authored by kylinos.com, but it was refused. No follow-up was found after that. [Link to the Patch] ( https://lore.kernel.org/lkml/20220401090828.614167-1-xieming@kylinos.cn/T/ ) - Another discussion went on in this email chain on 2022-05-09:, authored by nvidia.com, but no conclusion. https://lore.kernel.org/all/20210429162906.32742-1-sdonthineni@nvidia.com/ - As of this writing 2023-10-09, the issue still can be reproduced in kernel 6.1.x with Nvidia / AMD GPUs, on Arm arch. Problem Description: A GPU is passed through to a virtual machine via a PCIE node. When installing the GPU driver within a virtual machine that runs on Openeuler 22.03 LTS SP2 (aarch64) system (linux kernel 5.10 based), the following error occurs: “Unsupported FSC: EC=0x24 xFSC=0x21 ESR_EL2=0x92000061” PS: the same issue can also be reproduced in kernel 6.1.x with Nvidia / AMD GPUs. Upon consulting the official ARM documentation, the meanings of some of the error codes are as follows: EC=0x24 The binary code is 0b100100, which corresponds to a data abort. A possible cause of this problem could be alignment errors. xFSC=0x21 The binary code is 0b100001. Upon inquiry, this code represents an alignment error. There is a lack of online solutions to this error. KylinOS engineers once proposed a patch for this error, but it was rejected by the community. Moreover, their modification was based on the old 4.x kernel version. Link: [Link to the Patch]( https://lore.kernel.org/lkml/20220401090828.614167-1-xieming@kylinos.cn/T/) This patch suggests that it is unreasonable to set the I/O memory attributes of the virtual machine to Device_nGnRE type. According to ARM's official Whitepaper: Understanding Write Combining on Arm, Device-GRE is a type of relaxed-order memory that allows for gathering operations, but it does not allow for read speculation and imposes strict alignment constraints. You may refer to the table below or the following link for more information. [Link to ARM Community]( https://community.arm.com/arm-research/m/resources/1012 ) Preliminary Deduction: The GPU might be using Device-GRE type memory but without proper alignment, leading to the generation of this error. Thanks. Best regards, Guodong Xu Linaro

1 year, 2 months

3
2
0 0

2024

2023

2022

2021

2020