Received: by 10.223.185.116 with SMTP id b49csp1990038wrg; Mon, 12 Feb 2018 02:19:48 -0800 (PST) X-Google-Smtp-Source: AH8x225HTMusrAiWcc5qgj4IoQZhjIKUk9uINrAAlE1PP3Cf4GNbv6BcgL5775WETyxOzncWh65/ X-Received: by 2002:a17:902:68cb:: with SMTP id x11-v6mr10278733plm.198.1518430788037; Mon, 12 Feb 2018 02:19:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518430787; cv=none; d=google.com; s=arc-20160816; b=yIYzVz9NnaRepf7nX+MCnr2Ig6obt0tWV5p8eW89nxjo/OOtckAr5/qOCngsmgbUYT aZNk1Rkhp0g82VddkTekxftYGkALqejxAcI2utAD2cjOypcKqIR3MXue0cUHjaOWFxRr mXmVSsqnefKk9F0xDoWI8ymbldI7J5EYvhbZX3WZYGXb9d8aOKDMsE0N4vXIbt8qj6uK 9okUwnjLC1ayqNmnmm66yga2IfkwSQeUjY95fKOemNel2JvR0hAtsL9Sv4y2AYGThiYv QDe7Kzn/xztUa29mseXxaITTyntJfWRILOX7BGK7grexxgS/uspVu4EvCTYHalGQT4mx 81fQ== 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=9KFiI147PnzAPaM82a46VYd5KOd9fhz3ZAXEBh+dv1s=; b=yfRailJo2fAZfI4loV5CtOpJLhY7CS5IJ0zHiFHyabplyNtfnETYjQIPC+Qs5RIWXa sDqQI9xBaHpk/uxtfa2cZ93bCmTcebgPepNmxb8dvRG45Fb4qhe/I93BCEMyo0pyFPR4 4PYXoESPnxfIKI64mQsph9fPW+ZfsAsR/5sruYfE4bf7GTrlFC9HN41mbrkUw0nOFiff 20m+n+v+3vfbjwll2RE1J0h04slWOfiZzHz7sU6FqwiQEr2jraGsAsALSDxd2OfYHREk LqHYeI3B/6bq/KTyITZtDHs7A3FDvruelbKr0PgYROAg6qOe47c4OHziRlrRFU6wQxFg bvjw== 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 f32-v6si1789658plf.754.2018.02.12.02.19.34; Mon, 12 Feb 2018 02:19:47 -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 S1754029AbeBLKEw convert rfc822-to-8bit (ORCPT + 99 others); Mon, 12 Feb 2018 05:04:52 -0500 Received: from mail-qk0-f194.google.com ([209.85.220.194]:39507 "EHLO mail-qk0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754009AbeBLKEu (ORCPT ); Mon, 12 Feb 2018 05:04:50 -0500 Received: by mail-qk0-f194.google.com with SMTP id z197so883098qkb.6 for ; Mon, 12 Feb 2018 02:04:50 -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=GkERgt1Bv3NKelgRvJLB4Qz+jyaAX5G/gIKlhDBSpo8=; b=ZXGlvhY+2OxgIOP3Md6g+w8cZLBH0POGsib2bUThmlGOR6G8vq3zC5MaHRaeEAuo/t ST0dT6lO6A8sgd1dAA7x9mVvMMCRPGzi8TMGUlFXCzkuFpfWkVglp5j4gFbBkRWreSYp XfYVi/Xb0udj0yknxd5zTqawrOFWY4lgoe1lHmAB4Ljp7qJz1U1I3XCTDYBjmqzbprGO Q+M4nbzJv5NC0/okyy82AeP3SpdKVav5OUbbR6B9FDCLwGYPoLAfcnZP4TfLxelYRKGT v3+AZRpU4Ee7oX0dwzxOLBElRHeXk9s7dVzQlcZ7Gy8rLKegG3/vo04MM5QMtqux8ovC vidw== X-Gm-Message-State: APf1xPAumNbaWxTEaSIF6SHabIbq9W55A/pFiNNxDpMeCyvbywX2Qj3G 5cKAyQE8qJdcj6vqPxE2inPPrJcP6Pus01PJ5yRTaw== X-Received: by 10.55.73.140 with SMTP id w134mr17431847qka.215.1518429889695; Mon, 12 Feb 2018 02:04:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.146.233 with HTTP; Mon, 12 Feb 2018 02:04:49 -0800 (PST) In-Reply-To: <20180212053104-mutt-send-email-mst@kernel.org> References: <20180207013525.1634-1-marcandre.lureau@redhat.com> <20180207013525.1634-4-marcandre.lureau@redhat.com> <20180212053104-mutt-send-email-mst@kernel.org> From: Marc-Andre Lureau Date: Mon, 12 Feb 2018 11:04:49 +0100 Message-ID: Subject: Re: [PATCH v13 3/4] fw_cfg: write vmcoreinfo details 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:43 AM, Michael S. Tsirkin wrote: > On Wed, Feb 07, 2018 at 02:35:24AM +0100, Marc-André Lureau wrote: >> If the "etc/vmcoreinfo" fw_cfg file is present and we are not running >> the kdump kernel, write the addr/size of the vmcoreinfo ELF note. >> >> The DMA operation is expected to run synchronously with today qemu, >> but the specification states that it may become async, so we run >> "control" field check in a loop for eventual changes. >> >> Signed-off-by: Marc-André Lureau >> --- >> drivers/firmware/qemu_fw_cfg.c | 157 ++++++++++++++++++++++++++++++++++++++++- >> 1 file changed, 154 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmware/qemu_fw_cfg.c >> index 740df0df2260..fd576ba7b337 100644 >> --- a/drivers/firmware/qemu_fw_cfg.c >> +++ b/drivers/firmware/qemu_fw_cfg.c >> @@ -33,6 +33,9 @@ >> #include >> #include >> #include >> +#include >> +#include >> +#include >> >> MODULE_AUTHOR("Gabriel L. Somlo "); >> MODULE_DESCRIPTION("QEMU fw_cfg sysfs support"); >> @@ -43,12 +46,24 @@ MODULE_LICENSE("GPL"); >> #define FW_CFG_ID 0x01 >> #define FW_CFG_FILE_DIR 0x19 >> >> +#define FW_CFG_VERSION_DMA 0x02 >> +#define FW_CFG_DMA_CTL_ERROR 0x01 >> +#define FW_CFG_DMA_CTL_READ 0x02 >> +#define FW_CFG_DMA_CTL_SKIP 0x04 >> +#define FW_CFG_DMA_CTL_SELECT 0x08 >> +#define FW_CFG_DMA_CTL_WRITE 0x10 >> + >> /* size in bytes of fw_cfg signature */ >> #define FW_CFG_SIG_SIZE 4 >> >> /* fw_cfg "file name" is up to 56 characters (including terminating nul) */ >> #define FW_CFG_MAX_FILE_PATH 56 >> >> +#define VMCOREINFO_FORMAT_ELF 0x1 > > How about exporting interface parts in include/uapi/linux/ ? > QEMU can import it from there then. > This is what virtio does. Good idea, we didn't have it yet. So this is an additional change. I'll work on it. Though, if this should delay more this series, I think we should drop it. > >> + >> +/* fw_cfg revision attribute, in /sys/firmware/qemu_fw_cfg top-level dir. */ >> +static u32 fw_cfg_rev; >> + >> /* fw_cfg file directory entry type */ >> struct fw_cfg_file { >> u32 size; >> @@ -57,6 +72,12 @@ struct fw_cfg_file { >> char name[FW_CFG_MAX_FILE_PATH]; >> }; >> >> +struct fw_cfg_dma { >> + u32 control; >> + u32 length; >> + u64 address; >> +} __packed; >> + > > you can drop __packed here - it's always aligned properly. Isn't it preferable to make that explicit? Fwiw, qemu also declares the struct packed in its headers. > >> /* fw_cfg device i/o register addresses */ >> static bool fw_cfg_is_mmio; >> static phys_addr_t fw_cfg_p_base; >> @@ -75,6 +96,59 @@ static inline u16 fw_cfg_sel_endianness(u16 key) >> return fw_cfg_is_mmio ? cpu_to_be16(key) : cpu_to_le16(key); >> } >> >> +static inline bool fw_cfg_dma_enabled(void) >> +{ >> + return fw_cfg_rev & FW_CFG_VERSION_DMA && fw_cfg_reg_dma; > > Why do you use () with == below but not with && here? > Let's add them. >> +} >> + >> +/* qemu fw_cfg device is sync today, but spec says it may become async */ >> +static void fw_cfg_wait_for_control(struct fw_cfg_dma *d) >> +{ >> + do { >> + u32 ctrl = be32_to_cpu(READ_ONCE(d->control)); >> + >> + if ((ctrl & ~FW_CFG_DMA_CTL_ERROR) == 0) >> + return; >> + >> + usleep_range(50, 100); >> + } while (true); > > And you need an smp rmb here. Could you explain? thanks > >> +} >> + >> +static ssize_t fw_cfg_dma_transfer(void *address, u32 length, u32 control) >> +{ >> + phys_addr_t dma; >> + struct fw_cfg_dma *d = NULL; >> + ssize_t ret = length; >> + >> + d = kmalloc(sizeof(*d), GFP_KERNEL); >> + if (!d) { >> + ret = -ENOMEM; >> + goto end; >> + } >> + >> + *d = (struct fw_cfg_dma) { >> + .address = address ? cpu_to_be64(virt_to_phys(address)) : 0, >> + .length = cpu_to_be32(length), >> + .control = cpu_to_be32(control) >> + }; >> + >> + dma = virt_to_phys(d); > > Pls add docs on why this DMA bypasses the DMA API. Peter said in his patch: "fw_cfg device does not need IOMMU protection, so use physical addresses always. That's how QEMU implements fw_cfg. Otherwise we'll see call traces during boot." Is that enough justification? > >> + >> + iowrite32be((u64)dma >> 32, fw_cfg_reg_dma); >> + iowrite32be(dma, fw_cfg_reg_dma + 4); >> + >> + fw_cfg_wait_for_control(d); >> + >> + if (be32_to_cpu(READ_ONCE(d->control)) & FW_CFG_DMA_CTL_ERROR) { >> + ret = -EIO; >> + } >> + >> +end: >> + kfree(d); >> + >> + return ret; >> +} >> + >> /* 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) >> @@ -103,6 +177,47 @@ static inline void fw_cfg_read_blob(u16 key, >> acpi_release_global_lock(glk); >> } >> >> +#ifdef CONFIG_CRASH_CORE >> +/* write chunk of given fw_cfg blob (caller responsible for sanity-check) */ >> +static ssize_t fw_cfg_write_blob(u16 key, >> + void *buf, loff_t pos, size_t count) > > fw_cfg_dma_write seems like a nicer name. ok (I used the same naming as fw_cfg_read_blob() for consistency) > >> +{ >> + 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: >> + */ >> + status = acpi_acquire_global_lock(ACPI_WAIT_FOREVER, &glk); >> + if (ACPI_FAILURE(status) && status != AE_NOT_CONFIGURED) { >> + /* Should never get here */ >> + WARN(1, "%s: Failed to lock ACPI!\n", __func__); >> + return -EINVAL; >> + } >> + >> + mutex_lock(&fw_cfg_dev_lock); >> + if (pos == 0) { >> + ret = fw_cfg_dma_transfer(buf, count, key << 16 >> + | FW_CFG_DMA_CTL_SELECT >> + | FW_CFG_DMA_CTL_WRITE); >> + } 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_WRITE); >> + } >> + >> +end: >> + mutex_unlock(&fw_cfg_dev_lock); >> + >> + acpi_release_global_lock(glk); >> + >> + return ret; >> +} >> +#endif /* CONFIG_CRASH_CORE */ >> + >> /* clean up fw_cfg device i/o */ >> static void fw_cfg_io_cleanup(void) >> { >> @@ -201,9 +316,6 @@ static int fw_cfg_do_platform_probe(struct platform_device *pdev) >> return 0; >> } >> >> -/* fw_cfg revision attribute, in /sys/firmware/qemu_fw_cfg top-level dir. */ >> -static u32 fw_cfg_rev; >> - >> static ssize_t fw_cfg_showrev(struct kobject *k, struct attribute *a, char *buf) >> { >> return sprintf(buf, "%u\n", fw_cfg_rev); >> @@ -224,6 +336,37 @@ struct fw_cfg_sysfs_entry { >> struct list_head list; >> }; >> >> +#ifdef CONFIG_CRASH_CORE >> +static ssize_t write_vmcoreinfo(const struct fw_cfg_file *f) > > why not prefix with fw_cfg here? ok > >> +{ >> + struct vmci { >> + __le16 host_format; >> + __le16 guest_format; >> + __le32 size; >> + __le64 paddr; >> + } __packed; > > > No need for the __packed attribute. discussed above > And pls do not declare structures within functions. > Name them sanely and place in a header or near top of file. ok > >> + static struct vmci *data; >> + ssize_t ret; >> + >> + data = kmalloc(sizeof(struct vmci), GFP_KERNEL); >> + if (!data) >> + return -ENOMEM; >> + >> + *data = (struct vmci) { >> + .guest_format = cpu_to_le16(VMCOREINFO_FORMAT_ELF), >> + .size = cpu_to_le32(VMCOREINFO_NOTE_SIZE), >> + .paddr = cpu_to_le64(paddr_vmcoreinfo_note()) >> + }; >> + /* spare ourself reading host format support for now since we >> + * don't know what else to format - host may ignore ours >> + */ >> + ret = fw_cfg_write_blob(f->select, data, 0, sizeof(struct vmci)); >> + >> + kfree(data); >> + return ret; >> +} >> +#endif /* CONFIG_CRASH_CORE */ >> + >> /* get fw_cfg_sysfs_entry from kobject member */ >> static inline struct fw_cfg_sysfs_entry *to_entry(struct kobject *kobj) >> { >> @@ -464,6 +607,14 @@ static int fw_cfg_register_file(const struct fw_cfg_file *f) >> int err; >> struct fw_cfg_sysfs_entry *entry; >> >> +#ifdef CONFIG_CRASH_CORE >> + if (fw_cfg_dma_enabled() && >> + strcmp(f->name, "etc/vmcoreinfo") == 0 && !is_kdump_kernel()) { >> + if (write_vmcoreinfo(f) < 0) >> + pr_warn("fw_cfg: failed to write vmcoreinfo"); >> + } >> +#endif >> + >> /* allocate new entry */ >> entry = kzalloc(sizeof(*entry), GFP_KERNEL); >> if (!entry) >> -- >> 2.16.1.73.g5832b7e9f2 thanks