Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp3818734pxb; Tue, 7 Sep 2021 08:13:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyAWzUYsYktTIApMfFrdBd4biGd9F+qZrdr8qao/wN6aKO6hwm4CEKj+vOw5453xSk5D+4q X-Received: by 2002:a1c:f315:: with SMTP id q21mr4712136wmq.76.1631027629109; Tue, 07 Sep 2021 08:13:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631027629; cv=none; d=google.com; s=arc-20160816; b=cGjYwsE0d6oQC9YpqzbsbvKX7KVZsIrqGGVu1cjMcpR4T1KyIA526HOzK41T3BmZEV PEMOaCi3IPRCUcHc0/gpacXrVzKf9Y3PBMVT8bu5SlfhonMb2vHf/tVPXj0Gqxww3Z5/ RL1XYs8AXPMeeyWl7HgvR/yJojYe+/k0rfJ7YGbmM1bGy0Jd+KDx1irw1wA8kpjZ4x4u BBGVBWhkVDFk5i15RjJEx6VFPz5K+NeGyFqViW63YTO/nvQpgktILRRiRp3FqcTY5t7D viglW0NoVjkL/WFTanKW071APWU0iHCxWAJ2h2x3uJ+Qdav1Sj5NfYKIxGmRcoWBE5W3 YJRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=LIWIYbnDYl1i3WqG09yGksOeVFjcPDa46SZGycu/qXk=; b=Mj5PRIdr3wy44rgmNslTpyH98v5v60Wy0HvKc/L3FX7KLLoYl5/eKYzrGoHTSf7Gi5 B3iT7A+6U+pRJDkxY2Q4pU5rpUZbsbrRqOQdfJkJ/7qGYj5yZ/+yztDAZQAIdhk9HMG5 heGjgtUysLpuHyOKZ1l0z3g+Vmcmmhj59G+OIvQECafKfJlb1ENUc1m9WqbwAIlgmRYd BxxqPHHerTPNteXNU5T0Ee31nbYLjCrLsafV2C/Muiis0Tml4Z0ak/aDI1epXUvWrbH2 JzwF1gMS7D0UYPaXPq697hIrX1kqw4wyuiIqYKxURQ4+EP3Ryu6JfDIPuJJuO47xHGW7 +ReQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p18si11393110eds.16.2021.09.07.08.13.24; Tue, 07 Sep 2021 08:13:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236041AbhIGPLL (ORCPT + 99 others); Tue, 7 Sep 2021 11:11:11 -0400 Received: from mga14.intel.com ([192.55.52.115]:4937 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232090AbhIGPLL (ORCPT ); Tue, 7 Sep 2021 11:11:11 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10099"; a="219909052" X-IronPort-AV: E=Sophos;i="5.85,274,1624345200"; d="scan'208";a="219909052" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2021 08:10:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,274,1624345200"; d="scan'208";a="469228799" Received: from chenyu-desktop.sh.intel.com ([10.239.158.176]) by orsmga007.jf.intel.com with ESMTP; 07 Sep 2021 08:09:59 -0700 From: Chen Yu To: linux-acpi@vger.kernel.org Cc: linux-kernel@vger.kernel.org, "Rafael J. Wysocki" , Len Brown , Dan Williams , Andy Shevchenko , Aubrey Li , Ashok Raj , Chen Yu , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Jonathan Corbet , linux-doc@vger.kernel.org, x86@kernel.org Subject: [PATCH 1/5][RFC] Documentation: Introduce Platform Firmware Runtime Update documentation Date: Tue, 7 Sep 2021 23:15:46 +0800 Message-Id: X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Add the Platform Firmware Runtime Update/Telemetry documentation. Signed-off-by: Chen Yu --- Documentation/x86/pfru.rst | 98 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 98 insertions(+) create mode 100644 Documentation/x86/pfru.rst diff --git a/Documentation/x86/pfru.rst b/Documentation/x86/pfru.rst new file mode 100644 index 000000000000..321729f46737 --- /dev/null +++ b/Documentation/x86/pfru.rst @@ -0,0 +1,98 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================================================== +The Linux Platform Firmware Runtime Update and Telemetry +======================================================== + +According to the specification of [1], +certain computing systems require high Service Level Agreements (SLAs) where +system reboot fewer firmware updates are required to deploy firmware changes +to address bug fixes, security updates and to debug and root cause issues. This +technology is called Intel Seamless Update. The management mode (MM), +UEFI runtime services and ACPI services handle most of the system runtime +functions. Changing the MM code execution during runtime is called MM Runtime +Update. Since the "MM" acronyms might be misunderstood as "Memory Management", +this driver uses "Platform Firmware Runtime Update"(PFRU) + +PFRU provides the following facilities: Performs a runtime firmware driver update +and activate. Ability to inject firmware code at runtime, for dynamic instrumentation. +PFRU Telemetry is a service which allows Runtime Update handler to produce telemetry +data to upper layer OS consumer at runtime. The OS provides interfaces to let the +users query the telemetry data via read operations. The specification specifies the +interface and recommended policy to extract the data, the format and use are left to +individual OEM's and BIOS implementations on what that data represents. + +PFRU interfaces +===================== + +The user space tool manipulates on /dev/pfru/update for code injection and +driver update. PFRU stands for Platform Firmware Runtime Update, and the /dev/pfru +directory might be reserved for future usage. + + 1. mmap the capsule file + fd_capsule = open("capsule.cap", O_RDONLY); + fstat(fd_capsule, &stat); + addr = mmap(0, stat.st_size, PROT_READ, fd_capsule); + + 2. Get the capability information(version control, etc) from BIOS via + read() and do sanity check in user space. + fd_update = open("/dev/pfru/update", O_RDWR); + read(fd_update, &cap, sizeof(cap)); + sanity_check(&cap); + + 3. Write the capsule file to runtime update communication buffer + //kernel might return error if capsule file size is longer than + //communication buffer + write(fd_update, addr, stat.st_size); + + 4. Stage the code injection + ioctl(fd_update, PFRU_IOC_STATGE); + + 5. Activate the code injection + ioctl(fd_update, PFRU_IOC_ACTIVATE); + + 6. Stage and activate the code injection + ioctl(fd_update, PFRU_IOC_STAGE_ACTIVATE); + + PFRU_IOC_STATGE: Stage a capsule image from communication buffer + and perform authentication. + PFRU_IOC_ACTIVATE: Activate a previous staged capsule image. + PFRU_IOC_STAGE_ACTIVATE: Perform both stage and activation actions. + +PFRU Telemetry +============= + +The user space tool manipulates on /dev/pfru/telemetry for PFRU telemetry log. +Sample code: + + 1. Open telemetry device + fd_log = open("/dev/pfru/telemetry", O_RDWR); + + 2. Get log level, log type, revision_id via one ioctl invoke + ioctl(fd_log, PFRU_IOC_GET_LOG_INFO, &info); + + 3. Set log level, log type, revision_id + ioctl(fd_log, PFRU_IOC_SET_LOG_INFO, &info); + + 4. ioctl(fd_log, PFRU_IOC_GET_DATA_INFO, &data_info); + Query the information of PFRU telemetry log buffer. The user is + responsible for parsing the result per the specification. + + 5. Read the telemetry data: + read(fd_log, buf, data_info.size); + +Please refer to tools/testing/selftests/pfru/pfru_test.c for detail. + +According to [1], the telemetry +buffer is a wrap around buffer. If the telemetry buffer gets full, most recent +log data will overwrite old log data. Besides, it is required in the spec that +the read of telemetry should support both full data retrieval and delta telemetry +data retrieval. Since this requirement is more likely a policy we leave this +implementation in user space. That is to say, it is recommended for the user +to double-read the telemetry parameters such as chunk1_size, chunk2_size, +rollover_cnt in data_info structure to make sure that there is no more data appended +while the user is reading the buffer. Besides, only after the runtime update has +been run at least once, the telemetry log would have valid data, otherwise errno code +of EBUSY would be returned. + +[1] https://uefi.org/sites/default/files/resources/Intel_MM_OS_Interface_Spec_Rev100.pdf -- 2.25.1