Received: by 10.223.185.116 with SMTP id b49csp3164107wrg; Mon, 5 Mar 2018 15:32:34 -0800 (PST) X-Google-Smtp-Source: AG47ELs7hSUqwnOZ4aujIgnvYfu1L8M0YbciR6CZd0J2adfUmSfY88PQ5PCBkti/HWE7m7seg7J6 X-Received: by 2002:a17:902:8484:: with SMTP id c4-v6mr14472921plo.271.1520292754480; Mon, 05 Mar 2018 15:32:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520292754; cv=none; d=google.com; s=arc-20160816; b=sGX6DshYaD+j8zg6K6xgRn6PQQ03iOrr1BISP90Xixb5PjouSj33H46ExZM04cqGQF 49a6neO68GBMR68Ed50wveTXZvw1U40qFw9dtXRJfFAyJRrSNmJY+4K3vvQRNvEYJ+GI kc23mn+1QbXyI3VVTc5U/MXXdNTkCgyQf7I+LgZGnMhK1GPGqrW0vaK+Fs16yBXRXoGe AVQq5oRW0pSNM99oiD0G6brL4JpL5gKoBdk7VPaD167LHjrCY12/wTyQu+hXV14/fOeU aNeGMtMAYquKh04asEQXjwbgorrdphPhaia71Us05a1Z/rOPI9TXlQ5YnFpRp1msj/AB AwYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=bgstAN2iuzi3TLHh8o3LiHm3GUVrg15Bb0dgur2CfNA=; b=UU4t36fJi4Y5iksUy/xJCUzyhZuYwQ18h4BdHvHY9fLGBnGgrM3SWcjkV5TBUOuM7w O4WQBIugftz/q4M1dAbiCDRFne0zXy1pfaJfk2IktxzuOL0ETeMvjp1RpfoGENDxPBuT pqCrcZruEVUU3WXEDzlag44WAw8j/H1CbWongIYVmUQV4HO+VT2qlRkv6QygZz9NDPNj Z/2CjFPUk5X15qVffGzCZ86NjwOQaS+81Q4+VUdkHV4fauxMFok5AHpFpzMORyGFDgzC Yn5RajW3VzHQMJikwK86n6IB2q4RnOkCAGAxz0lLZBwoSueOeRPDhCqYrPHLIsBcGujU zzIA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p23si6892885pgv.371.2018.03.05.15.32.20; Mon, 05 Mar 2018 15:32:34 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932922AbeCEXac (ORCPT + 99 others); Mon, 5 Mar 2018 18:30:32 -0500 Received: from mga02.intel.com ([134.134.136.20]:47760 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932636AbeCEX3k (ORCPT ); Mon, 5 Mar 2018 18:29:40 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2018 15:29:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,429,1515484800"; d="scan'208";a="25443533" Received: from sai-dev-mach.sc.intel.com ([143.183.140.145]) by fmsmga002.fm.intel.com with ESMTP; 05 Mar 2018 15:29:39 -0800 From: Sai Praneeth Prakhya To: linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Sai Praneeth , Lee@vger.kernel.org, Chun-Yi , Borislav Petkov , Tony Luck , Will Deacon , Dave Hansen , Mark Rutland , Bhupesh Sharma , Ricardo Neri , Ravi Shankar , Matt Fleming , Peter Zijlstra , Ard Biesheuvel , Dan Williams Subject: [PATCH V2 2/3] efi: Introduce efi_rts_workqueue and some infrastructure to invoke all efi_runtime_services() Date: Mon, 5 Mar 2018 15:23:09 -0800 Message-Id: <1520292190-5027-3-git-send-email-sai.praneeth.prakhya@intel.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1520292190-5027-1-git-send-email-sai.praneeth.prakhya@intel.com> References: <1520292190-5027-1-git-send-email-sai.praneeth.prakhya@intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Sai Praneeth When a process requests the kernel to execute any efi_runtime_service(), the requested efi_runtime_service (represented as an identifier) and its arguments are packed into a struct named efi_runtime_work and queued onto work queue named efi_rts_wq. The caller then waits until the work is completed. Introduce some infrastructure: 1. Creating workqueue named efi_rts_wq 2. A macro (efi_queue_work()) that a. populates efi_runtime_work b. queues work onto efi_rts_wq and c. waits until worker thread returns The caller thread has to wait until the worker thread returns, because it's dependent on the return status of efi_runtime_service() and, in specific cases, the arguments populated by efi_runtime_service(). Some efi_runtime_services() takes a pointer to buffer as an argument and fills up the buffer with requested data. For instance, efi_get_variable() and efi_get_next_variable(). Hence, caller process cannot just post the work and get going. Some facts about efi_runtime_services(): 1. A quick look at all the efi_runtime_services() shows that any efi_runtime_service() has five or less arguments. 2. An argument of efi_runtime_service() can be a value (of any type) or a pointer (of any type). Hence, efi_runtime_work has five void pointers to store these arguments. Signed-off-by: Sai Praneeth Prakhya Suggested-by: Andy Lutomirski Cc: Lee, Chun-Yi Cc: Borislav Petkov Cc: Tony Luck Cc: Will Deacon Cc: Dave Hansen Cc: Mark Rutland Cc: Bhupesh Sharma Cc: Ricardo Neri Cc: Ravi Shankar Cc: Matt Fleming Cc: Peter Zijlstra Cc: Ard Biesheuvel Cc: Dan Williams --- drivers/firmware/efi/efi.c | 15 ++++++++ drivers/firmware/efi/runtime-wrappers.c | 61 +++++++++++++++++++++++++++++++++ include/linux/efi.h | 20 +++++++++++ 3 files changed, 96 insertions(+) diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c index 838b8efe639c..04b46c62f3ce 100644 --- a/drivers/firmware/efi/efi.c +++ b/drivers/firmware/efi/efi.c @@ -75,6 +75,8 @@ static unsigned long *efi_tables[] = { &efi.mem_attr_table, }; +struct workqueue_struct *efi_rts_wq; + static bool disable_runtime; static int __init setup_noefi(char *arg) { @@ -329,6 +331,19 @@ static int __init efisubsys_init(void) return 0; /* + * Since we process only one efi_runtime_service() at a time, an + * ordered workqueue (which creates only one execution context) + * should suffice all our needs. + */ + efi_rts_wq = alloc_ordered_workqueue("efi_rts_workqueue", 0); + if (!efi_rts_wq) { + pr_err("Failed to create efi_rts_workqueue, EFI runtime services " + "disabled.\n"); + clear_bit(EFI_RUNTIME_SERVICES, &efi.flags); + return 0; + } + + /* * Clean DUMMY object calls EFI Runtime Service, set_variable(), so * it should be invoked only after efi_rts_workqueue is ready. */ diff --git a/drivers/firmware/efi/runtime-wrappers.c b/drivers/firmware/efi/runtime-wrappers.c index ae54870b2788..649763171439 100644 --- a/drivers/firmware/efi/runtime-wrappers.c +++ b/drivers/firmware/efi/runtime-wrappers.c @@ -1,6 +1,14 @@ /* * runtime-wrappers.c - Runtime Services function call wrappers * + * Implementation summary: + * ----------------------- + * 1. When user/kernel thread requests to execute efi_runtime_service(), + * enqueue work to efi_rts_workqueue. + * 2. Caller thread waits until the work is finished because it's + * dependent on the return status and execution of efi_runtime_service(). + * For instance, get_variable() and get_next_variable(). + * * Copyright (C) 2014 Linaro Ltd. * * Split off from arch/x86/platform/efi/efi.c @@ -22,6 +30,8 @@ #include #include #include +#include + #include /* @@ -33,6 +43,57 @@ #define __efi_call_virt(f, args...) \ __efi_call_virt_pointer(efi.systab->runtime, f, args) +/* efi_runtime_service() function identifiers */ +enum { + GET_TIME, + SET_TIME, + GET_WAKEUP_TIME, + SET_WAKEUP_TIME, + GET_VARIABLE, + GET_NEXT_VARIABLE, + SET_VARIABLE, + SET_VARIABLE_NONBLOCKING, + QUERY_VARIABLE_INFO, + QUERY_VARIABLE_INFO_NONBLOCKING, + GET_NEXT_HIGH_MONO_COUNT, + RESET_SYSTEM, + UPDATE_CAPSULE, + QUERY_CAPSULE_CAPS, +}; + +/* + * efi_queue_work: Queue efi_runtime_service() and wait until it's done + * @rts: efi_runtime_service() function identifier + * @rts_arg<1-5>: efi_runtime_service() function arguments + * + * Accesses to efi_runtime_services() are serialized by a binary + * semaphore (efi_runtime_lock) and caller waits until the work is + * finished, hence _only_ one work is queued at a time and the queued + * work gets flushed. + */ +#define efi_queue_work(_rts, _arg1, _arg2, _arg3, _arg4, _arg5) \ +({ \ + struct efi_runtime_work efi_rts_work; \ + \ + INIT_WORK_ONSTACK(&efi_rts_work.work, efi_call_rts); \ + efi_rts_work.func = _rts; \ + efi_rts_work.arg1 = _arg1; \ + efi_rts_work.arg2 = _arg2; \ + efi_rts_work.arg3 = _arg3; \ + efi_rts_work.arg4 = _arg4; \ + efi_rts_work.arg5 = _arg5; \ + /* \ + * queue_work() returns 0 if work was already on queue, \ + * _ideally_ this should never happen. \ + */ \ + if (queue_work(efi_rts_wq, &efi_rts_work.work)) \ + flush_work(&efi_rts_work.work); \ + else \ + BUG(); \ + \ + efi_rts_work.status; \ +}) + void efi_call_virt_check_flags(unsigned long flags, const char *call) { unsigned long cur_flags, mismatch; diff --git a/include/linux/efi.h b/include/linux/efi.h index c4efb3ef0dfa..bb06b71af55c 100644 --- a/include/linux/efi.h +++ b/include/linux/efi.h @@ -1652,4 +1652,24 @@ struct linux_efi_tpm_eventlog { extern int efi_tpm_eventlog_init(void); +/* + * efi_runtime_work: Details of EFI Runtime Service work + * @func: EFI Runtime Service function identifier + * @arg<1-5>: EFI Runtime Service function arguments + * @status: Status of executing EFI Runtime Service + */ +struct efi_runtime_work { + u8 func; + void *arg1; + void *arg2; + void *arg3; + void *arg4; + void *arg5; + efi_status_t status; + struct work_struct work; +}; + +/* Workqueue to queue EFI Runtime Services */ +extern struct workqueue_struct *efi_rts_wq; + #endif /* _LINUX_EFI_H */ -- 2.7.4