Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

18 participants
2389 discussions

Re: (subset) [PATCH v7 03/16] dt-bindings: mfd: mediatek: Add codec property for MT6357 PMIC

by Lee Jones

On Mon, 22 Jul 2024 08:53:32 +0200, Alexandre Mergnat wrote: > Add the audio codec sub-device. This sub-device is used to set the > optional voltage values according to the hardware. > The properties are: > - Setup of microphone bias voltage. > - Setup of the speaker pin pull-down. > > Also, add the audio power supply property which is dedicated for > the audio codec sub-device. > > [...] Applied, thanks! [03/16] dt-bindings: mfd: mediatek: Add codec property for MT6357 PMIC commit: 3821149eb101fe2d45a4697659e60930828400d8 -- Lee Jones [李琼斯]

1 day, 7 hours

Re: (subset) [PATCH RESEND v5 03/16] dt-bindings: mfd: mediatek: Add codec property for MT6357 PMIC

by Lee Jones

On Fri, 14 Jun 2024 09:27:46 +0200, Alexandre Mergnat wrote: > Add the audio codec sub-device. This sub-device is used to set the > optional voltage values according to the hardware. > The properties are: > - Setup of microphone bias voltage. > - Setup of the speaker pin pull-down. > > Also, add the audio power supply property which is dedicated for > the audio codec sub-device. > > [...] Applied, thanks! [03/16] dt-bindings: mfd: mediatek: Add codec property for MT6357 PMIC commit: 3821149eb101fe2d45a4697659e60930828400d8 -- Lee Jones [李琼斯]

1 day, 7 hours

Re: [PATCH RFC 1/3] firmware: qcom: implement object invoke support

by Dmitry Baryshkov

On Thu, 25 Jul 2024 at 07:15, Amirreza Zarrabi <quic_azarrabi(a)quicinc.com> wrote: > > > > On 7/25/2024 2:09 PM, Dmitry Baryshkov wrote: > > On Thu, Jul 25, 2024 at 01:19:07PM GMT, Amirreza Zarrabi wrote: > >> > >> > >> On 7/4/2024 5:34 PM, Dmitry Baryshkov wrote: > >>> On Thu, 4 Jul 2024 at 00:40, Amirreza Zarrabi <quic_azarrabi(a)quicinc.com> wrote: > >>>> > >>>> > >>>> > >>>> On 7/3/2024 10:13 PM, Dmitry Baryshkov wrote: > >>>>> On Tue, Jul 02, 2024 at 10:57:36PM GMT, Amirreza Zarrabi wrote: > >>>>>> Qualcomm TEE hosts Trusted Applications and Services that run in the > >>>>>> secure world. Access to these resources is provided using object > >>>>>> capabilities. A TEE client with access to the capability can invoke > >>>>>> the object and request a service. Similarly, TEE can request a service > >>>>>> from nonsecure world with object capabilities that are exported to secure > >>>>>> world. > >>>>>> > >>>>>> We provide qcom_tee_object which represents an object in both secure > >>>>>> and nonsecure world. TEE clients can invoke an instance of qcom_tee_object > >>>>>> to access TEE. TEE can issue a callback request to nonsecure world > >>>>>> by invoking an instance of qcom_tee_object in nonsecure world. > >>>>> > >>>>> Please see Documentation/process/submitting-patches.rst on how to write > >>>>> commit messages. > >>>> > >>>> Ack. > >>>> > >>>>> > >>>>>> > >>>>>> Any driver in nonsecure world that is interested to export a struct (or a > >>>>>> service object) to TEE, requires to embed an instance of qcom_tee_object in > >>>>>> the relevant struct and implements the dispatcher function which is called > >>>>>> when TEE invoked the service object. > >>>>>> > >>>>>> We also provids simplified API which implements the Qualcomm TEE transport > >>>>>> protocol. The implementation is independent from any services that may > >>>>>> reside in nonsecure world. > >>>>> > >>>>> "also" usually means that it should go to a separate commit. > >>>> > >>>> I will split this patch to multiple smaller ones. > >>>> > >>> > >>> [...] > >>> > >>>>> > >>>>>> + } in, out; > >>>>>> +}; > >>>>>> + > >>>>>> +int qcom_tee_object_do_invoke(struct qcom_tee_object_invoke_ctx *oic, > >>>>>> + struct qcom_tee_object *object, unsigned long op, struct qcom_tee_arg u[], int *result); > >>>>> > >>>>> What's the difference between a result that gets returned by the > >>>>> function and the result that gets retuned via the pointer? > >>>> > >>>> The function result, is local to kernel, for instance memory allocation failure, > >>>> or failure to issue the smc call. The result in pointer, is the remote result, > >>>> for instance return value from TA, or the TEE itself. > >>>> > >>>> I'll use better name, e.g. 'remote_result'? > >>> > >>> See how this is handled by other parties. For example, PSCI. If you > >>> have a standard set of return codes, translate them to -ESOMETHING in > >>> your framework and let everybody else see only the standard errors. > >>> > >>> > >> > >> I can not hide this return value, they are TA dependent. The client to a TA > >> needs to see it, just knowing that something has failed is not enough in > >> case they need to do something based on that. I can not even translate them > >> as they are TA related so the range is unknown. > > > > I'd say it a sad design. At least error values should be standard. > > > > Sure. But it is normal. If we finally move to TEE subsystem, this is the value that > would be copied to struct tee_ioctl_invoke_arg.ret to pass to the caller of > TEE_IOC_INVOKE. Ack -- With best wishes Dmitry

1 day, 19 hours

Re: [PATCH RFC 1/3] firmware: qcom: implement object invoke support

by Dmitry Baryshkov

On Thu, Jul 25, 2024 at 01:19:07PM GMT, Amirreza Zarrabi wrote: > > > On 7/4/2024 5:34 PM, Dmitry Baryshkov wrote: > > On Thu, 4 Jul 2024 at 00:40, Amirreza Zarrabi <quic_azarrabi(a)quicinc.com> wrote: > >> > >> > >> > >> On 7/3/2024 10:13 PM, Dmitry Baryshkov wrote: > >>> On Tue, Jul 02, 2024 at 10:57:36PM GMT, Amirreza Zarrabi wrote: > >>>> Qualcomm TEE hosts Trusted Applications and Services that run in the > >>>> secure world. Access to these resources is provided using object > >>>> capabilities. A TEE client with access to the capability can invoke > >>>> the object and request a service. Similarly, TEE can request a service > >>>> from nonsecure world with object capabilities that are exported to secure > >>>> world. > >>>> > >>>> We provide qcom_tee_object which represents an object in both secure > >>>> and nonsecure world. TEE clients can invoke an instance of qcom_tee_object > >>>> to access TEE. TEE can issue a callback request to nonsecure world > >>>> by invoking an instance of qcom_tee_object in nonsecure world. > >>> > >>> Please see Documentation/process/submitting-patches.rst on how to write > >>> commit messages. > >> > >> Ack. > >> > >>> > >>>> > >>>> Any driver in nonsecure world that is interested to export a struct (or a > >>>> service object) to TEE, requires to embed an instance of qcom_tee_object in > >>>> the relevant struct and implements the dispatcher function which is called > >>>> when TEE invoked the service object. > >>>> > >>>> We also provids simplified API which implements the Qualcomm TEE transport > >>>> protocol. The implementation is independent from any services that may > >>>> reside in nonsecure world. > >>> > >>> "also" usually means that it should go to a separate commit. > >> > >> I will split this patch to multiple smaller ones. > >> > > > > [...] > > > >>> > >>>> + } in, out; > >>>> +}; > >>>> + > >>>> +int qcom_tee_object_do_invoke(struct qcom_tee_object_invoke_ctx *oic, > >>>> + struct qcom_tee_object *object, unsigned long op, struct qcom_tee_arg u[], int *result); > >>> > >>> What's the difference between a result that gets returned by the > >>> function and the result that gets retuned via the pointer? > >> > >> The function result, is local to kernel, for instance memory allocation failure, > >> or failure to issue the smc call. The result in pointer, is the remote result, > >> for instance return value from TA, or the TEE itself. > >> > >> I'll use better name, e.g. 'remote_result'? > > > > See how this is handled by other parties. For example, PSCI. If you > > have a standard set of return codes, translate them to -ESOMETHING in > > your framework and let everybody else see only the standard errors. > > > > > > I can not hide this return value, they are TA dependent. The client to a TA > needs to see it, just knowing that something has failed is not enough in > case they need to do something based on that. I can not even translate them > as they are TA related so the range is unknown. I'd say it a sad design. At least error values should be standard. -- With best wishes Dmitry

1 day, 19 hours

Re: [PATCH v7 03/16] dt-bindings: mfd: mediatek: Add codec property for MT6357 PMIC

by Krzysztof Kozlowski

On 22/07/2024 08:53, Alexandre Mergnat wrote: > Add the audio codec sub-device. This sub-device is used to set the > optional voltage values according to the hardware. > The properties are: > - Setup of microphone bias voltage. > - Setup of the speaker pin pull-down. > > Also, add the audio power supply property which is dedicated for > the audio codec sub-device. > > Signed-off-by: Alexandre Mergnat <amergnat(a)baylibre.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Best regards, Krzysztof

2 days, 16 hours

Re: [PATCH RFC 1/3] firmware: qcom: implement object invoke support

by Krzysztof Kozlowski

On 03/07/2024 07:57, Amirreza Zarrabi wrote: > Qualcomm TEE hosts Trusted Applications and Services that run in the > secure world. Access to these resources is provided using object > capabilities. A TEE client with access to the capability can invoke > the object and request a service. Similarly, TEE can request a service > from nonsecure world with object capabilities that are exported to secure > world. > > We provide qcom_tee_object which represents an object in both secure > and nonsecure world. TEE clients can invoke an instance of qcom_tee_object > to access TEE. TEE can issue a callback request to nonsecure world > by invoking an instance of qcom_tee_object in nonsecure world. > > Any driver in nonsecure world that is interested to export a struct (or a > service object) to TEE, requires to embed an instance of qcom_tee_object in > the relevant struct and implements the dispatcher function which is called > when TEE invoked the service object. > > We also provids simplified API which implements the Qualcomm TEE transport > protocol. The implementation is independent from any services that may > reside in nonsecure world. > > Signed-off-by: Amirreza Zarrabi <quic_azarrabi(a)quicinc.com> > --- > drivers/firmware/qcom/Kconfig | 14 + > drivers/firmware/qcom/Makefile | 2 + > drivers/firmware/qcom/qcom_object_invoke/Makefile | 4 + > drivers/firmware/qcom/qcom_object_invoke/async.c | 142 +++ > drivers/firmware/qcom/qcom_object_invoke/core.c | 1139 ++++++++++++++++++++ > drivers/firmware/qcom/qcom_object_invoke/core.h | 186 ++++ > .../qcom/qcom_object_invoke/qcom_scm_invoke.c | 22 + > .../firmware/qcom/qcom_object_invoke/release_wq.c | 90 ++ > include/linux/firmware/qcom/qcom_object_invoke.h | 233 ++++ > 9 files changed, 1832 insertions(+) > > diff --git a/drivers/firmware/qcom/Kconfig b/drivers/firmware/qcom/Kconfig > index 7f6eb4174734..103ab82bae9f 100644 > --- a/drivers/firmware/qcom/Kconfig > +++ b/drivers/firmware/qcom/Kconfig > @@ -84,4 +84,18 @@ config QCOM_QSEECOM_UEFISECAPP > Select Y here to provide access to EFI variables on the aforementioned > platforms. > > +config QCOM_OBJECT_INVOKE_CORE Let's avoid another rant from Linus and add here either proper defaults or dependencies. > + bool "Secure TEE Communication Support" > + help > + Various Qualcomm SoCs have a Trusted Execution Environment (TEE) running > + in the Trust Zone. This module provides an interface to that via the > + capability based object invocation, using SMC calls. > + > + OBJECT_INVOKE_CORE allows capability based secure communication between > + TEE and VMs. Using OBJECT_INVOKE_CORE, kernel can issue calls to TEE or > + TAs to request a service or exposes services to TEE and TAs. It implements > + the necessary marshaling of messages with TEE. > + > + Select Y here to provide access to TEE. > + > endmenu > diff --git a/drivers/firmware/qcom/Makefile b/drivers/firmware/qc ... > + } else { > + /* TEE obtained the ownership of QCOM_TEE_OBJECT_TYPE_CB_OBJECT > + * input objects in 'u'. On further failure, TEE is responsible > + * to release them. > + */ > + > + oic->flags |= OIC_FLAG_QCOM_TEE; > + } > + > + /* Is it a callback request?! */ > + if (response_type != QCOM_TEE_RESULT_INBOUND_REQ_NEEDED) { > + if (!*result) { > + ret = update_args(u, oic); > + if (ret) { > + arg_for_each_output_object(i, u) > + put_qcom_tee_object(u[i].o); > + } > + } > + > + break; > + > + } else { > + oic->flags |= OIC_FLAG_BUSY; > + > + /* Before dispatching the request, handle any pending async requests. */ > + __fetch__async_reqs(oic); > + > + qcom_tee_object_invoke(oic, cb_msg); > + } > + } > + > + __fetch__async_reqs(oic); > + > +out: > + qcom_tee_object_invoke_ctx_uninit(oic); > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(qcom_tee_object_do_invoke); > + > +/* Primordial Object. */ > +/* It is invoked by TEE for kernel services. */ > + > +static struct qcom_tee_object *primordial_object = NULL_QCOM_TEE_OBJECT; > +static DEFINE_MUTEX(primordial_object_lock); Oh my... except that it looks like undocumented ABI, please avoid file-scope variables. Best regards, Krzysztof

1 week, 1 day

Re: [PATCH RFC 0/3] Implement Qualcomm TEE IPC and ioctl calls

by Dmitry Baryshkov

Adding TEE mailing list and maintainers to the CC list. Amirreza, please include them in future even if you are not going to use the framework. On Wed, Jul 10, 2024 at 09:16:48AM GMT, Amirreza Zarrabi wrote: > > > On 7/3/2024 9:36 PM, Dmitry Baryshkov wrote: > > On Tue, Jul 02, 2024 at 10:57:35PM GMT, Amirreza Zarrabi wrote: > >> Qualcomm TEE hosts Trusted Applications (TAs) and services that run in > >> the secure world. Access to these resources is provided using MinkIPC. > >> MinkIPC is a capability-based synchronous message passing facility. It > >> allows code executing in one domain to invoke objects running in other > >> domains. When a process holds a reference to an object that lives in > >> another domain, that object reference is a capability. Capabilities > >> allow us to separate implementation of policies from implementation of > >> the transport. > >> > >> As part of the upstreaming of the object invoke driver (called SMC-Invoke > >> driver), we need to provide a reasonable kernel API and UAPI. The clear > >> option is to use TEE subsystem and write a back-end driver, however the > >> TEE subsystem doesn't fit with the design of Qualcomm TEE. > >> > > To answer your "general comment", maybe a bit of background :). > > Traditionally, policy enforcement is based on access-control models, > either (1) access-control list or (2) capability [0]. A capability is an > opaque ("non-forge-able") object reference that grants the holder the > right to perform certain operations on the object (e.g. Read, Write, > Execute, or Grant). Capabilities are preferred mechanism for representing > a policy, due to their fine-grained representation of access right, inline > with > (P1) the principle of least privilege [1], and > (P2) the ability to avoid the confused deputy problem [2]. > > [0] Jack B. Dennis and Earl C. Van Horn. 1966. Programming Semantics for > Multiprogrammed Computations. Commun. ACM 9 (1966), 143–155. > > [1] Jerome H. Saltzer and Michael D. Schroeder. 1975. The Protection of > Information in Computer Systems. Proc. IEEE 63 (1975), 1278–1308. > > [2] Norm Hardy. 1988. The Confused Deputy (or Why Capabilities Might Have > Been Invented). ACM Operating Systems Review 22, 4 (1988), 36–38. > > For MinkIPC, an object represents a TEE or TA service. The reference to > the object is the "handle" that is returned from TEE (let's call it > TEE-Handle). The supported operations are "service invocation" (similar > to Execute), and "sharing access to a service" (similar to Grant). > Anyone with access to the TEE-Handle can invoke the service or pass the > TEE-Handle to someone else to access the same service. > > The responsibility of the MinkIPC framework is to hide the TEE-Handle, > so that the client can not forge it, and allow the owner of the handle > to transfer it to other clients as it wishes. Using a file descriptor > table we can achieve that. We wrap the TEE-Handle as a FD and let the > client invoke FD (e.g. using IOCTL), or transfer the FD (e.g. using > UNIX socket). > > As a side note, for the sake of completeness, capabilities are fundamentally > a "discretionary mechanism", as the holder of the object reference has the > ability to share it with others. A secure system requires "mandatory > enforcement" (i.e. ability to revoke authority and ability to control > the authority propagation). This is out of scope for the MinkIPC. > MinkIPC is only interested in P1 and P2 (mention above). > > > >> Does TEE subsystem fit requirements of a capability based system? > >> ----------------------------------------------------------------- > >> In TEE subsystem, to invoke a function: > >> - client should open a device file "/dev/teeX", > >> - create a session with a TA, and > >> - invoke the functions in that session. > >> > >> 1. The privilege to invoke a function is determined by a session. If a > >> client has a session, it cannot share it with other clients. Even if > >> it does, it is not fine-grained enough, i.e. either all accessible > >> functions/resources in a session or none. Assume a scenario when a client > >> wants to grant a permission to invoke just a function that it has the rights, > >> to another client. > >> > >> The "all or nothing" for sharing sessions is not in line with our > >> capability system: "if you own a capability, you should be able to grant > >> or share it". > > > > Can you please be more specific here? What kind of sharing is expected > > on the user side of it? > > In MinkIPC, after authenticating a client credential, a TA (or TEE) may > return multiple TEE-Handles, each representing a service that the client > has privilege to access. The client should be able to "individually" > reference each TEE-Handle, e.g. to invoke and share it (as per capability- > based system requirements). > > If we use TEE subsystem, which has a session based design, all TEE-Handles > are meaningful with respect to the session in which they are allocated, > hence the use of "__u32 session" in "struct tee_ioctl_invoke_arg". > > Here, we have a contradiction with MinkIPC. We may ignore the session > and say "even though a TEE-Handle is allocated in a session but it is also > valid outside a session", i.e. the session-id in TEE uapi becomes redundant > (a case of divergence from definition). > > > > >> 2. In TEE subsystem, resources are managed in a context. Every time a > >> client opens "/dev/teeX", a new context is created to keep track of > >> the allocated resources, including opened sessions and remote objects. Any > >> effort for sharing resources between two independent clients requires > >> involvement of context manager, i.e. the back-end driver. This requires > >> implementing some form of policy in the back-end driver. > > > > What kind of resource sharing? > > TEE subsystem "rightfully" allocates a context each time a client opens > a device file. This context pass around to the backend driver to identify > independent clients that opened the device file. > > The context is used by backend driver to keep track of the resources. Type > of resources are TEE driver dependent. As an example of resource in TEE > subsystem, you can look into 'shm' register and unregister (specially, > see comment in function 'shm_alloc_helper'). > > For MinkIPC, all clients are treated the same and the TEE-Handles are > representative of the resources, accessible "globally" if a client has the > capability for them. In kernel, clients access an object if they have > access to "qcom_tee_object", in userspace, clients access an object if > they have the FD wrapper for the TEE-Handle. > > If we use context, instead of the file descriptor table, any form of object > transfer requires involvement of the backend driver. If we use the file > descriptor table, contexts are becoming useless for MinkIPC (i.e. > 'ctx->data' will "always" be null). > > > > >> 3. The TEE subsystem supports two type of memory sharing: > >> - per-device memory pools, and > >> - user defined memory references. > >> User defined memory references are private to the application and cannot > >> be shared. Memory allocated from per-device "shared" pools are accessible > >> using a file descriptor. It can be mapped by any process if it has > >> access to it. This means, we cannot provide the resource isolation > >> between two clients. Assume a scenario when a client wants to allocate a > >> memory (which is shared with TEE) from an "isolated" pool and share it > >> with another client, without the right to access the contents of memory. > > > > This doesn't explain, why would it want to share such memory with > > another client. > > Ok, I believe there is a misunderstanding here. I did not try to justify > specific usecase. We want to separate the memory allocation from the > framework. This way, how the memory is obtained, e.g. it is allocated > (1) from an isolated pool, (2) a shared pool, (3) a secure heap, > (4) a system dma-heap, (5) process address space, or (6) other memory > with "different constraints", becomes independent. > > We introduced "memory object" type. User implements a kernel service > using "qcom_tee_object" to represent the memory object. We have an > implementation of memory objects based on dma-buf. > > > > >> 4. The kernel API provided by TEE subsystem does not support a kernel > >> supplicant. Adding support requires an execution context (e.g. a > >> kernel thread) due to the TEE subsystem design. tee_driver_ops supports > >> only "send" and "receive" callbacks and to deliver a request, someone > >> should wait on "receive". > > > > There is nothing wrong here, but maybe I'm misunderstanding something. > > I agree. But, I am trying to re-emphasize how useful TEE subsystem is > for MinkIPC. For kernel services, we solely rely on the backend driver. > For instance, to expose RPMB service we will use "qcom_tee_object". > So there is nothing provided by the framework to simplify the service > development. > > > > >> We need a callback to "dispatch" or "handle" a request in the context of > >> the client thread. It should redirect a request to a kernel service or > >> a user supplicant. In TEE subsystem such requirement should be implemented > >> in TEE back-end driver, independent from the TEE subsystem. > >> > >> 5. The UAPI provided by TEE subsystem is similar to the GPTEE Client > >> interface. This interface is not suitable for a capability system. > >> For instance, there is no session in a capability system which means > >> either its should not be used, or we should overload its definition. > > > > General comment: maybe adding more detailed explanation of how the > > capabilities are aquired and how they can be used might make sense. > > > > BTW. It might be my imperfect English, but each time I see the word > > 'capability' I'm thinking that some is capable of doing something. I > > find it hard to use 'capability' for the reference to another object. > > > > Explained at the top :). > > >> > >> Can we use TEE subsystem? > >> ------------------------- > >> There are workarounds for some of the issues above. The question is if we > >> should define our own UAPI or try to use a hack-y way of fitting into > >> the TEE subsystem. I am using word hack-y, as most of the workaround > >> involves: > >> > >> - "diverging from the definition". For instance, ignoring the session > >> open and close ioctl calls or use file descriptors for all remote > >> resources (as, fd is the closet to capability) which undermines the > >> isolation provided by the contexts, > >> > >> - "overloading the variables". For instance, passing object ID as file > >> descriptors in a place of session ID, or > >> > >> - "bypass TEE subsystem". For instance, extensively rely on meta > >> parameters or push everything (e.g. kernel services) to the back-end > >> driver, which means leaving almost all TEE subsystem unused. > >> > >> We cannot take the full benefits of TEE subsystem and may need to > >> implement most of the requirements in the back-end driver. Also, as > >> discussed above, the UAPI is not suitable for capability-based use cases. > >> We proposed a new set of ioctl calls for SMC-Invoke driver. > >> > >> In this series we posted three patches. We implemented a transport > >> driver that provides qcom_tee_object. Any object on secure side is > >> represented with an instance of qcom_tee_object and any struct exposed > >> to TEE should embed an instance of qcom_tee_object. Any, support for new > >> services, e.g. memory object, RPMB, userspace clients or supplicants are > >> implemented independently from the driver. > >> > >> We have a simple memory object and a user driver that uses > >> qcom_tee_object. > > > > Could you please point out any user for the uAPI? I'd like to understand > > how does it from from the userspace point of view. > > Sure :), I'll write up a test patch and send it in next series. > > Summary. > > TEE framework provides some nice facilities, including: > - uapi and ioctl interface, > - marshaling parameters and context management, > - memory mapping and sharing, and > - TEE bus and TA drivers. > > For, MinkIPC, we will not use any of them. The only usable piece, is uapi > interface which is not suitable for MinkIPC, as discussed above. > > > > >> > >> Signed-off-by: Amirreza Zarrabi <quic_azarrabi(a)quicinc.com> > >> --- > >> Amirreza Zarrabi (3): > >> firmware: qcom: implement object invoke support > >> firmware: qcom: implement memory object support for TEE > >> firmware: qcom: implement ioctl for TEE object invocation > >> > >> drivers/firmware/qcom/Kconfig | 36 + > >> drivers/firmware/qcom/Makefile | 2 + > >> drivers/firmware/qcom/qcom_object_invoke/Makefile | 12 + > >> drivers/firmware/qcom/qcom_object_invoke/async.c | 142 +++ > >> drivers/firmware/qcom/qcom_object_invoke/core.c | 1139 ++++++++++++++++++ > >> drivers/firmware/qcom/qcom_object_invoke/core.h | 186 +++ > >> .../qcom/qcom_object_invoke/qcom_scm_invoke.c | 22 + > >> .../firmware/qcom/qcom_object_invoke/release_wq.c | 90 ++ > >> .../qcom/qcom_object_invoke/xts/mem_object.c | 406 +++++++ > >> .../qcom_object_invoke/xts/object_invoke_uapi.c | 1231 ++++++++++++++++++++ > >> include/linux/firmware/qcom/qcom_object_invoke.h | 233 ++++ > >> include/uapi/misc/qcom_tee.h | 117 ++ > >> 12 files changed, 3616 insertions(+) > >> --- > >> base-commit: 74564adfd3521d9e322cfc345fdc132df80f3c79 > >> change-id: 20240702-qcom-tee-object-and-ioctls-6f52fde03485 > >> > >> Best regards, > >> -- > >> Amirreza Zarrabi <quic_azarrabi(a)quicinc.com> > >> > > -- With best wishes Dmitry

1 week, 1 day

Re: [PATCH 1/2] dma-buf: heaps: DMA_HEAP_IOCTL_ALLOC_READ_FILE framework

by Christoph Hellwig

On Thu, Jul 18, 2024 at 09:51:39AM +0800, Huan Yang wrote: > Yes, actually, if dma-buf want's to copy_file_range from a file, it need > change something in vfs_copy_file_range: No, it doesn't. copy_file_range is specifically designed to copy inside a single file system as already mentioned. The generic offload for copying between arbitrary FDs is splice and the sendfile convenience wrapper around it

1 week, 1 day

Re: [PATCH 1/2] dma-buf: heaps: DMA_HEAP_IOCTL_ALLOC_READ_FILE framework

by Daniel Vetter

On Tue, Jul 16, 2024 at 06:14:48PM +0800, Huan Yang wrote: > > 在 2024/7/16 17:31, Daniel Vetter 写道: > > [你通常不会收到来自 daniel.vetter(a)ffwll.ch 的电子邮件。请访问 https://aka.ms/LearnAboutSenderIdentification，以了解这一点为什么很重要] > > > > On Tue, Jul 16, 2024 at 10:48:40AM +0800, Huan Yang wrote: > > > I just research the udmabuf, Please correct me if I'm wrong. > > > > > > 在 2024/7/15 20:32, Christian König 写道: > > > > Am 15.07.24 um 11:11 schrieb Daniel Vetter: > > > > > On Thu, Jul 11, 2024 at 11:00:02AM +0200, Christian König wrote: > > > > > > Am 11.07.24 um 09:42 schrieb Huan Yang: > > > > > > > Some user may need load file into dma-buf, current > > > > > > > way is: > > > > > > > 1. allocate a dma-buf, get dma-buf fd > > > > > > > 2. mmap dma-buf fd into vaddr > > > > > > > 3. read(file_fd, vaddr, fsz) > > > > > > > This is too heavy if fsz reached to GB. > > > > > > You need to describe a bit more why that is to heavy. I can only > > > > > > assume you > > > > > > need to save memory bandwidth and avoid the extra copy with the CPU. > > > > > > > > > > > > > This patch implement a feature called DMA_HEAP_IOCTL_ALLOC_READ_FILE. > > > > > > > User need to offer a file_fd which you want to load into > > > > > > > dma-buf, then, > > > > > > > it promise if you got a dma-buf fd, it will contains the file content. > > > > > > Interesting idea, that has at least more potential than trying > > > > > > to enable > > > > > > direct I/O on mmap()ed DMA-bufs. > > > > > > > > > > > > The approach with the new IOCTL might not work because it is a very > > > > > > specialized use case. > > > > > > > > > > > > But IIRC there was a copy_file_range callback in the file_operations > > > > > > structure you could use for that. I'm just not sure when and how > > > > > > that's used > > > > > > with the copy_file_range() system call. > > > > > I'm not sure any of those help, because internally they're all still > > > > > based > > > > > on struct page (or maybe in the future on folios). And that's the thing > > > > > dma-buf can't give you, at least without peaking behind the curtain. > > > > > > > > > > I think an entirely different option would be malloc+udmabuf. That > > > > > essentially handles the impendence-mismatch between direct I/O and > > > > > dma-buf > > > > > on the dma-buf side. The downside is that it'll make the permanently > > > > > pinned memory accounting and tracking issues even more apparent, but I > > > > > guess eventually we do need to sort that one out. > > > > Oh, very good idea! > > > > Just one minor correction: it's not malloc+udmabuf, but rather > > > > create_memfd()+udmabuf. > > Hm right, it's create_memfd() + mmap(memfd) + udmabuf > > > > > > And you need to complete your direct I/O before creating the udmabuf > > > > since that reference will prevent direct I/O from working. > > > udmabuf will pin all pages, so, if returned fd, can't trigger direct I/O > > > (same as dmabuf). So, must complete read before pin it. > > Why does pinning prevent direct I/O? I haven't tested, but I'd expect the > > rdma folks would be really annoyed if that's the case ... > > > > > But current way is use `memfd_pin_folios` to boost alloc and pin, so maybe > > > need suit it. > > > > > > > > > I currently doubt that the udmabuf solution is suitable for our > > > gigabyte-level read operations. > > > > > > 1. The current mmap operation uses faulting, so frequent page faults will be > > > triggered during reads, resulting in a lot of context switching overhead. > > > > > > 2. current udmabuf size limit is 64MB, even can change, maybe not good to > > > use in large size? > > Yeah that's just a figleaf so we don't have to bother about the accounting > > issue. > > > > > 3. The migration and adaptation of the driver is also a challenge, and > > > currently, we are unable to control it. > > Why does a udmabuf fd not work instead of any other dmabuf fd? That > > shouldn't matter for the consuming driver ... > > Hmm, our production's driver provider by other oem. I see many of they > implement > > their own dma_buf_ops. These may not be generic and may require them to > reimplement. Yeah, for exporting a buffer object allocated by that driver. But any competent gles/vk stack also supports importing dma-buf, and that should work with udmabuf exactly the same way as with a dma-buf allocated from the system heap. > > > Perhaps implementing `copy_file_range` would be more suitable for us. > > See my other mail, fundamentally these all rely on struct page being > > present, and dma-buf doesn't give you that. Which means you need to go > > below the dma-buf abstraction. And udmabuf is pretty much the thing for > > that, because it wraps normal struct page memory into a dmabuf. > Yes, udmabuf give this, I am very interested in whether the page provided by > udmabuf can trigger direct I/O. > > So, I'll give a test and report soon. > > > > And copy_file_range on the underlying memfd might already work, I haven't > > checked though. > > I have doubts. > > I recently tested and found that I need to modify many places in > vfs_copy_file_range in order to run the copy file range with DMA_BUF fd.(I > have managed to get it working, I'm talking about memfd, not dma-buf here. I think copy_file_range to dma-buf is as architecturally unsound as allowing O_DIRECT on the dma-buf mmap. Cheers, Sima > but I don't think the implementation is good enough, so I can't provide the > source code.) > > Maybe memfd can work or not, let's give it a test.:) > > Anyway, it's a good idea too. I currently need to focus on whether it can be > achieved, as well as the performance comparison. > > > > > Cheers, Sima > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch/ -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

1 week, 2 days

Re: [PATCH 1/2] dma-buf: heaps: DMA_HEAP_IOCTL_ALLOC_READ_FILE framework

by Daniel Vetter

On Tue, Jul 16, 2024 at 10:48:40AM +0800, Huan Yang wrote: > I just research the udmabuf, Please correct me if I'm wrong. > > 在 2024/7/15 20:32, Christian König 写道: > > Am 15.07.24 um 11:11 schrieb Daniel Vetter: > > > On Thu, Jul 11, 2024 at 11:00:02AM +0200, Christian König wrote: > > > > Am 11.07.24 um 09:42 schrieb Huan Yang: > > > > > Some user may need load file into dma-buf, current > > > > > way is: > > > > > 1. allocate a dma-buf, get dma-buf fd > > > > > 2. mmap dma-buf fd into vaddr > > > > > 3. read(file_fd, vaddr, fsz) > > > > > This is too heavy if fsz reached to GB. > > > > You need to describe a bit more why that is to heavy. I can only > > > > assume you > > > > need to save memory bandwidth and avoid the extra copy with the CPU. > > > > > > > > > This patch implement a feature called DMA_HEAP_IOCTL_ALLOC_READ_FILE. > > > > > User need to offer a file_fd which you want to load into > > > > > dma-buf, then, > > > > > it promise if you got a dma-buf fd, it will contains the file content. > > > > Interesting idea, that has at least more potential than trying > > > > to enable > > > > direct I/O on mmap()ed DMA-bufs. > > > > > > > > The approach with the new IOCTL might not work because it is a very > > > > specialized use case. > > > > > > > > But IIRC there was a copy_file_range callback in the file_operations > > > > structure you could use for that. I'm just not sure when and how > > > > that's used > > > > with the copy_file_range() system call. > > > I'm not sure any of those help, because internally they're all still > > > based > > > on struct page (or maybe in the future on folios). And that's the thing > > > dma-buf can't give you, at least without peaking behind the curtain. > > > > > > I think an entirely different option would be malloc+udmabuf. That > > > essentially handles the impendence-mismatch between direct I/O and > > > dma-buf > > > on the dma-buf side. The downside is that it'll make the permanently > > > pinned memory accounting and tracking issues even more apparent, but I > > > guess eventually we do need to sort that one out. > > > > Oh, very good idea! > > Just one minor correction: it's not malloc+udmabuf, but rather > > create_memfd()+udmabuf. Hm right, it's create_memfd() + mmap(memfd) + udmabuf > > And you need to complete your direct I/O before creating the udmabuf > > since that reference will prevent direct I/O from working. > > udmabuf will pin all pages, so, if returned fd, can't trigger direct I/O > (same as dmabuf). So, must complete read before pin it. Why does pinning prevent direct I/O? I haven't tested, but I'd expect the rdma folks would be really annoyed if that's the case ... > But current way is use `memfd_pin_folios` to boost alloc and pin, so maybe > need suit it. > > > I currently doubt that the udmabuf solution is suitable for our > gigabyte-level read operations. > > 1. The current mmap operation uses faulting, so frequent page faults will be > triggered during reads, resulting in a lot of context switching overhead. > > 2. current udmabuf size limit is 64MB, even can change, maybe not good to > use in large size? Yeah that's just a figleaf so we don't have to bother about the accounting issue. > 3. The migration and adaptation of the driver is also a challenge, and > currently, we are unable to control it. Why does a udmabuf fd not work instead of any other dmabuf fd? That shouldn't matter for the consuming driver ... > Perhaps implementing `copy_file_range` would be more suitable for us. See my other mail, fundamentally these all rely on struct page being present, and dma-buf doesn't give you that. Which means you need to go below the dma-buf abstraction. And udmabuf is pretty much the thing for that, because it wraps normal struct page memory into a dmabuf. And copy_file_range on the underlying memfd might already work, I haven't checked though. Cheers, Sima -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

1 week, 2 days

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig