Received: by 10.223.185.116 with SMTP id b49csp2175989wrg; Mon, 12 Feb 2018 05:42:14 -0800 (PST) X-Google-Smtp-Source: AH8x226jgMkRQEPXPlEP2ruOExPR3uZdFtNucwhmsCmaoRiP/4qBpR+H9s31iKJGb34aE4sBaEF/ X-Received: by 2002:a17:902:8f90:: with SMTP id z16-v6mr10985792plo.370.1518442933914; Mon, 12 Feb 2018 05:42:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518442933; cv=none; d=google.com; s=arc-20160816; b=o7oNRnToqiKvg8jjnJt+L+EojkQbH+eH/eVL9923wDkBb7yz7ov+yQ4YWuaK2r2nT3 Qu/x+/oniJD1PrzqrcMPpOMV3DYDyQWk3W7UBveAP/Q2vGRln0M/tehdrFHmh4QNPR9i kfwmwC7c8eKY/yiY4KRpOzOWLhh2r8IKNnVjO8zQW3yrvtMuYDHkY2B/NrFjdvA/dO4e 2LWi1VTr64oAyU8+2+qdC84iZCFHuu+/h49iLFpOFaoDtMq96fFs7+zBAEyq0nwL4SLK Z9SvcZmeR8Flu3QK/NeRyjoeWxPZV5k3FXrK6zUmLi1PcTIIY9z99K/a//vfBl/rn5WW kG2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :arc-authentication-results; bh=u9Zme6G3RnSobp2VJnXrLOlxBJsFT4mtz+ynGujekM4=; b=wYK8AmO6amZsIURLID9fjwYdCO2ouSzbTBV0laKHwhgbNcDIjBueZMi1e8V5CxTY02 BKTbiDV/tNHIPw2oWZoz/rUABkyWZ5y7dUnjdcBB9vCI0t95tMoTJEomUS54vOEpz6JI 056pIzibBRlosIxnqeWeaURzobvqCXCkb6ZJI4q9zmUp1ajyGbej3f8iaSveJpHQXjZY WhkkODATP/bzTLT/k4lI9nSQK9lCNJyVymbwtOTfZ4bnJ1JDy9qLkLDOFkqHzIW315DZ teHnOhbbwD8ariU3d/0y+KoxgW/p7zMxCYh9L0PHvFXG1ShkMvNCWNX1kUtWGzl7TLZy H5IQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 66-v6si2378509pla.131.2018.02.12.05.41.59; Mon, 12 Feb 2018 05:42:13 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934438AbeBLMQm convert rfc822-to-8bit (ORCPT + 99 others); Mon, 12 Feb 2018 07:16:42 -0500 Received: from mail-qt0-f193.google.com ([209.85.216.193]:36206 "EHLO mail-qt0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933136AbeBLMQl (ORCPT ); Mon, 12 Feb 2018 07:16:41 -0500 Received: by mail-qt0-f193.google.com with SMTP id q18so11887080qtl.3 for ; Mon, 12 Feb 2018 04:16:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZFN/2Lk/0PIATYSdlHKcvS8g9AoOPdFGwQjLQFrCdUo=; b=bnuXmWvJInHFbHhnsXYb/AeL7BDLWyclwRkj0H1J3FtMtQKdCaS8/A9gWHcTloSVqt SbNvHyTAg+MKJJkaZayM86LkFMr/u8oaIxB8tZLSjO3VDuSs2ANnpTozq8fkCVr6HTaN Y5zSKDsHjk834Tx1LgwMpPTqhgi28QHUYGMRz248fyA3ccZeBSAJ8mma56G61PeCOMqM lcAVb/A9vBWJvZlRmhYD39UG0/7XxyGtMSiHUZOZ7RmjnWmuSeA3dkgidek6W00ArGwr UN5eRq7tM4zPkcExOF39v2X6lfBNoOIXuk0ewwTEJkdXZLwmYCia7w4wEX9J1XsOY+lm 2XSA== X-Gm-Message-State: APf1xPCAaHxgsrZgzVMpiI6aYB/ibHDCseB2N2S4svhhfnshjvMJ4rMA TXyC5q8lVcifo6KbzfThH42X+1rBHwStmuZ6K5UV8A== X-Received: by 10.237.49.130 with SMTP id 2mr17723578qth.19.1518437800434; Mon, 12 Feb 2018 04:16:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.146.233 with HTTP; Mon, 12 Feb 2018 04:16:40 -0800 (PST) In-Reply-To: <20180212052710-mutt-send-email-mst@kernel.org> References: <20180207013525.1634-1-marcandre.lureau@redhat.com> <20180207013525.1634-5-marcandre.lureau@redhat.com> <20180212052710-mutt-send-email-mst@kernel.org> From: Marc-Andre Lureau Date: Mon, 12 Feb 2018 13:16:40 +0100 Message-ID: Subject: Re: [PATCH v13 4/4] RFC: fw_cfg: do DMA read operation To: "Michael S. Tsirkin" Cc: =?UTF-8?B?TWFyYy1BbmRyw6kgTHVyZWF1?= , Linux Kernel Mailing List , Sergio Lopez Pascual , Baoquan He , "Somlo, Gabriel" , xiaolong.ye@intel.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi On Mon, Feb 12, 2018 at 4:30 AM, Michael S. Tsirkin wrote: > On Wed, Feb 07, 2018 at 02:35:25AM +0100, Marc-André Lureau wrote: >> Modify fw_cfg_read_blob() to use DMA if the device supports it. >> Return errors, because the operation may fail. >> >> So far, only one call in fw_cfg_register_dir_entries() is using >> kmalloc'ed buf and is thus clearly eligible to DMA read. >> >> Initially, I didn't implement DMA read to speed up boot time, but as a >> first step before introducing DMA write (since read operations were >> already presents). Even more, I didn't realize fw-cfg entries were >> being read by the kernel during boot by default. But actally fw-cfg >> entries are being populated during module probe. I knew DMA improved a >> lot bios boot time (the main reason the DMA interface was added >> afaik). Let see the time it would take to read the whole ACPI >> tables (128kb allocated) >> >> # time cat /sys/firmware/qemu_fw_cfg/by_name/etc/acpi/tables/raw >> - with DMA: sys 0m0.003s >> - without DMA (-global fw_cfg.dma_enabled=off): sys 0m7.674s >> >> FW_CFG_FILE_DIR (0x19) is the only "file" that is read during kernel >> boot to populate sysfs qemu_fw_cfg directory, and it is quite >> small (1-2kb). Since it does not expose itself, in order to measure >> the time it takes to read such small file, I took a comparable sized >> file of 2048 bytes and exposed it (-fw_cfg test,file=file with a >> modified read_raw enabling DMA) >> >> # perf stat -r 100 cat /sys/firmware/qemu_fw_cfg/by_name/test/raw >/dev/null >> - with DMA: >> 0.636037 task-clock (msec) # 0.141 CPUs utilized ( +- 1.19% ) >> - without DMA: >> 6.430128 task-clock (msec) # 0.622 CPUs utilized ( +- 0.22% ) >> >> That's a few msec saved during boot by enabling DMA read (the gain >> would be more substantial if other & bigger fw-cfg entries are read by >> others from sysfs, unfortunately, it's not clear if we can always >> enable DMA there) >> >> Signed-off-by: Marc-André Lureau >> --- >> drivers/firmware/qemu_fw_cfg.c | 47 ++++++++++++++++++++++++++++++------------ >> 1 file changed, 34 insertions(+), 13 deletions(-) >> >> diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmware/qemu_fw_cfg.c >> index fd576ba7b337..3721dc868a2b 100644 >> --- a/drivers/firmware/qemu_fw_cfg.c >> +++ b/drivers/firmware/qemu_fw_cfg.c >> @@ -150,11 +150,13 @@ static ssize_t fw_cfg_dma_transfer(void *address, u32 length, u32 control) >> } >> >> /* read chunk of given fw_cfg blob (caller responsible for sanity-check) */ >> -static inline void fw_cfg_read_blob(u16 key, >> - void *buf, loff_t pos, size_t count) >> +static ssize_t fw_cfg_read_blob(u16 key, >> + void *buf, loff_t pos, size_t count, >> + bool dma) >> { >> u32 glk = -1U; >> acpi_status status; >> + ssize_t ret = count; >> >> /* If we have ACPI, ensure mutual exclusion against any potential >> * device access by the firmware, e.g. via AML methods: >> @@ -164,17 +166,36 @@ static inline void fw_cfg_read_blob(u16 key, >> /* Should never get here */ >> WARN(1, "fw_cfg_read_blob: Failed to lock ACPI!\n"); >> memset(buf, 0, count); >> - return; >> + return -EINVAL; >> } >> >> mutex_lock(&fw_cfg_dev_lock); >> - iowrite16(fw_cfg_sel_endianness(key), fw_cfg_reg_ctrl); >> - while (pos-- > 0) >> - ioread8(fw_cfg_reg_data); >> - ioread8_rep(fw_cfg_reg_data, buf, count); >> + if (dma && fw_cfg_dma_enabled()) { >> + if (pos == 0) { >> + ret = fw_cfg_dma_transfer(buf, count, key << 16 >> + | FW_CFG_DMA_CTL_SELECT >> + | FW_CFG_DMA_CTL_READ); >> + } else { >> + iowrite16(fw_cfg_sel_endianness(key), fw_cfg_reg_ctrl); >> + ret = fw_cfg_dma_transfer(NULL, pos, FW_CFG_DMA_CTL_SKIP); >> + if (ret < 0) >> + goto end; >> + ret = fw_cfg_dma_transfer(buf, count, >> + FW_CFG_DMA_CTL_READ); >> + } >> + } else { >> + iowrite16(fw_cfg_sel_endianness(key), fw_cfg_reg_ctrl); >> + while (pos-- > 0) >> + ioread8(fw_cfg_reg_data); >> + ioread8_rep(fw_cfg_reg_data, buf, count); >> + } >> + >> +end: >> mutex_unlock(&fw_cfg_dev_lock); >> >> acpi_release_global_lock(glk); >> + >> + return ret; >> } >> > > These two functions share no common code at all. > Pls name the dma one fw_cfg_dma_read or something like this, > cleaner than a flag. They share arguments, ACPI locking, error handling, cleanup. But they also allow to abstract read over dma-capable and non-dma capable. I'll split both cases in two functions. > >> #ifdef CONFIG_CRASH_CORE >> @@ -307,7 +328,7 @@ static int fw_cfg_do_platform_probe(struct platform_device *pdev) >> #endif >> >> /* verify fw_cfg device signature */ >> - fw_cfg_read_blob(FW_CFG_SIGNATURE, sig, 0, FW_CFG_SIG_SIZE); >> + fw_cfg_read_blob(FW_CFG_SIGNATURE, sig, 0, FW_CFG_SIG_SIZE, false); >> if (memcmp(sig, "QEMU", FW_CFG_SIG_SIZE) != 0) { >> fw_cfg_io_cleanup(); >> return -ENODEV; > > BTW it looks like fw_cfg_read_blob can fail and that failure isn't > handled properly here. ok > >> @@ -494,8 +515,8 @@ static ssize_t fw_cfg_sysfs_read_raw(struct file *filp, struct kobject *kobj, >> if (count > entry->f.size - pos) >> count = entry->f.size - pos; >> >> - fw_cfg_read_blob(entry->f.select, buf, pos, count); >> - return count; >> + /* do not use DMA, virt_to_phys(buf) might not be ok */ >> + return fw_cfg_read_blob(entry->f.select, buf, pos, count, false); >> } >> >> static struct bin_attribute fw_cfg_sysfs_attr_raw = { >> @@ -656,7 +677,7 @@ static int fw_cfg_register_dir_entries(void) >> struct fw_cfg_file *dir; >> size_t dir_size; >> >> - fw_cfg_read_blob(FW_CFG_FILE_DIR, &count, 0, sizeof(count)); >> + fw_cfg_read_blob(FW_CFG_FILE_DIR, &count, 0, sizeof(count), false); >> count = be32_to_cpu(count); >> dir_size = count * sizeof(struct fw_cfg_file); >> >> @@ -664,7 +685,7 @@ static int fw_cfg_register_dir_entries(void) >> if (!dir) >> return -ENOMEM; >> >> - fw_cfg_read_blob(FW_CFG_FILE_DIR, dir, sizeof(count), dir_size); >> + fw_cfg_read_blob(FW_CFG_FILE_DIR, dir, sizeof(count), dir_size, true); >> >> for (i = 0; i < count; i++) { >> dir[i].size = be32_to_cpu(dir[i].size); >> @@ -713,7 +734,7 @@ static int fw_cfg_sysfs_probe(struct platform_device *pdev) >> goto err_probe; >> >> /* get revision number, add matching top-level attribute */ >> - fw_cfg_read_blob(FW_CFG_ID, &fw_cfg_rev, 0, sizeof(fw_cfg_rev)); >> + fw_cfg_read_blob(FW_CFG_ID, &fw_cfg_rev, 0, sizeof(fw_cfg_rev), false); >> fw_cfg_rev = le32_to_cpu(fw_cfg_rev); >> err = sysfs_create_file(fw_cfg_top_ko, &fw_cfg_rev_attr.attr); >> if (err) >> -- >> 2.16.1.73.g5832b7e9f2