lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 2 Aug 2022 17:07:51 +0530 From: Rajendra Nayak <quic_rjendra@...cinc.com> To: Guru Das Srinagesh <quic_gurus@...cinc.com>, Andy Gross <agross@...nel.org>, Bjorn Andersson <bjorn.andersson@...aro.org>, "Philipp Zabel" <p.zabel@...gutronix.de>, <linux-arm-msm@...r.kernel.org>, <linux-kernel@...r.kernel.org> CC: David Heidelberg <david@...t.cz>, Robert Marko <robimarko@...il.com>, Elliot Berman <quic_eberman@...cinc.com> Subject: Re: [PATCH v2 4/5] firmware: qcom: scm: Add wait-queue helper functions On 7/23/2022 4:07 AM, Guru Das Srinagesh wrote: > When the firmware (FW) supports multiple requests per VM, and the VM > also supports it via the `allow-multi-call` device tree flag, the > floodgates are thrown open for them to all reach the firmware at the > same time. > > Since the firmware currently being used has limited resources, it guards > them with a resource lock and puts requests on a wait-queue internally > and signals to HLOS that it is doing so. It does this by returning two > new return values in addition to success or error: SCM_WAITQ_SLEEP and > SCM_WAITQ_WAKE. > > 1) SCM_WAITQ_SLEEP: > > When an SCM call receives this return value instead of success > or error, FW has placed this call on a wait-queue and > has signalled HLOS to put it to non-interruptible sleep. (The > mechanism to wake it back up will be described in detail in the > next patch for the sake of simplicity.) > > Along with this return value, FW also passes to HLOS `wq_ctx` - > a unique number (UID) identifying the wait-queue that it has put > the call on, internally. This is to help HLOS with its own > bookkeeping to wake this sleeping call later. > > Additionally, FW also passes to HLOS `smc_call_ctx` - a UID > identifying the SCM call thus being put to sleep. This is also > for HLOS' bookkeeping to wake this call up later. > > These two additional values are passed via the a1 and a2 > registers. > > N.B.: The "ctx" in the above UID names = "context". > > 2) SCM_WAITQ_WAKE: > > When an SCM call receives this return value instead of success > or error, FW wishes to signal HLOS to wake up a (different) > previously sleeping call. > > FW tells HLOS which call to wake up via the additional return > values `wq_ctx`, `smc_call_ctx` and `flags`. The first two have > already been explained above. > > `flags` can be either WAKE_ONE or WAKE_ALL. Meaning, wake either > one, or all, of the SCM calls that HLOS is associating with the > given `wq_ctx`. > > A sleeping SCM call can be woken up by either an interrupt that FW > raises, or via a SCM_WAITQ_WAKE return value for a new SCM call. Do you know why the FW was not designed to always use an interrupt? That would have made the handling of this in kernel a lot less complicated. > The handshake mechanism that HLOS uses to talk to FW about wait-queue > operations involves three new SMC calls. These are: > > 1) get_wq_ctx(): > > Arguments: None > Returns: wq_ctx, flags, more_pending > > Get the wait-queue context, and wake up either one or all of the > sleeping SCM calls associated with that wait-queue. > > Additionally, repeat this if there are more wait-queues that are > ready to have their requests woken up (`more_pending`). > > 2) wq_resume(smc_call_ctx): > > Arguments: smc_call_ctx > > HLOS needs to issue this in response to receiving an > IRQ, passing to FW the same smc_call_ctx that FW > receives from HLOS via the get_wq_ctx() call. > > 3) wq_wake_ack(smc_call_ctx): > > Arguments: smc_call_ctx > > HLOS needs to issue this in response to receiving an > SCM_WAITQ_WAKE, passing to FW the same smc_call_ctx that FW > passed to HLOS via the SMC_WAITQ_WAKE call. > > (Reminder that the full handshake mechanism will be detailed in the > subsequent patch.) > > Also add the interrupt handler that wakes up a sleeping SCM call. > > Signed-off-by: Guru Das Srinagesh <quic_gurus@...cinc.com> > --- [].. > +struct completion *qcom_scm_lookup_wq(struct qcom_scm *scm, u32 wq_ctx) > +{ > + struct completion *wq = NULL; > + u32 wq_ctx_idr = wq_ctx; > + unsigned long flags; > + int err; > + > + spin_lock_irqsave(&scm->waitq.idr_lock, flags); > + wq = idr_find(&scm->waitq.idr, wq_ctx); > + if (wq) > + goto out; > + > + wq = devm_kzalloc(scm->dev, sizeof(*wq), GFP_ATOMIC); > + if (!wq) { > + wq = ERR_PTR(-ENOMEM); > + goto out; > + } > + > + init_completion(wq); > + > + err = idr_alloc_u32(&scm->waitq.idr, wq, &wq_ctx_idr, > + U32_MAX, GFP_ATOMIC); > + if (err < 0) { > + devm_kfree(scm->dev, wq); > + wq = ERR_PTR(err); > + } > + > +out: > + spin_unlock_irqrestore(&scm->waitq.idr_lock, flags); > + return wq; > +} > + > +void scm_waitq_flag_handler(struct completion *wq, u32 flags) > +{ > + switch (flags) { > + case QCOM_SMC_WAITQ_FLAG_WAKE_ONE: > + complete(wq); > + break; > + case QCOM_SMC_WAITQ_FLAG_WAKE_ALL: > + complete_all(wq); > + break; > + default: > + pr_err("invalid flags: %u\n", flags); > + } > +} > + > +static void scm_irq_work(struct work_struct *work) > +{ > + int ret; > + u32 wq_ctx, flags, more_pending = 0; > + struct completion *wq_to_wake; > + struct qcom_scm_waitq *w = container_of(work, struct qcom_scm_waitq, scm_irq_work); > + struct qcom_scm *scm = container_of(w, struct qcom_scm, waitq); > + > + do { > + ret = scm_get_wq_ctx(&wq_ctx, &flags, &more_pending); > + if (ret) { > + pr_err("GET_WQ_CTX SMC call failed: %d\n", ret); > + return; > + } > + > + wq_to_wake = qcom_scm_lookup_wq(scm, wq_ctx); > + if (IS_ERR_OR_NULL(wq_to_wake)) { > + pr_err("No waitqueue found for wq_ctx %d: %ld\n", > + wq_ctx, PTR_ERR(wq_to_wake)); > + return; What happens if at this point 'more_pending' was true? will the FW raise another interrupt? > + } > + > + scm_waitq_flag_handler(wq_to_wake, flags); > + } while (more_pending); > +}
Powered by blists - more mailing lists