Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751255AbeAPGLM (ORCPT + 1 other); Tue, 16 Jan 2018 01:11:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40856 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750892AbeAPGLL (ORCPT ); Tue, 16 Jan 2018 01:11:11 -0500 Date: Tue, 16 Jan 2018 14:11:02 +0800 From: Peter Xu To: Marc-Andre Lureau Cc: qemu-devel , Linux Kernel Mailing List , "Michael S . Tsirkin" , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , Baoquan He Subject: Re: [PATCH] fw_cfg: don't use DMA mapping for fw_cfg device Message-ID: <20180116061102.GA7031@xz-mi> References: <20180115085528.32663-1-peterx@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 16 Jan 2018 06:11:11 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Mon, Jan 15, 2018 at 12:22:48PM +0100, Marc-Andre Lureau wrote: > Hi > > On Mon, Jan 15, 2018 at 9:55 AM, Peter Xu wrote: > > 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 when vIOMMU is enabled in guest: > > > > [ 1.018306] ------------[ cut here ]------------ > > [ 1.018314] WARNING: CPU: 1 PID: 1 at drivers/firmware/qemu_fw_cfg.c:152 fw_cfg_dma_transfer+0x399/0x500 > > [ 1.018315] fw_cfg_dma_transfer: failed to map fw_cfg_dma > > [ 1.018316] Modules linked in: > > [ 1.018320] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.10.0-827.el7.x86_64 #1 > > [ 1.018321] Hardware name: Red Hat KVM, BIOS 1.11.0-1.el7 04/01/2014 > > [ 1.018322] Call Trace: > > [ 1.018330] [] dump_stack+0x19/0x1b > > [ 1.018334] [] __warn+0xd8/0x100 > > [ 1.018336] [] warn_slowpath_fmt+0x5f/0x80 > > [ 1.018338] [] fw_cfg_dma_transfer+0x399/0x500 > > [ 1.018340] [] fw_cfg_read_blob+0xac/0x1c0 > > [ 1.018342] [] fw_cfg_register_dir_entries+0x80/0x450 > > [ 1.018344] [] fw_cfg_sysfs_probe+0x212/0x3f0 > > [ 1.018347] [] platform_drv_probe+0x42/0x110 > > [ 1.018350] [] driver_probe_device+0xc2/0x3e0 > > [ 1.018352] [] __driver_attach+0x93/0xa0 > > [ 1.018354] [] ? __device_attach+0x40/0x40 > > [ 1.018359] [] bus_for_each_dev+0x73/0xc0 > > [ 1.018362] [] driver_attach+0x1e/0x20 > > [ 1.018364] [] bus_add_driver+0x200/0x2d0 > > [ 1.018366] [] ? firmware_map_add_early+0x58/0x58 > > [ 1.018368] [] driver_register+0x64/0xf0 > > [ 1.018370] [] __platform_driver_register+0x4a/0x50 > > [ 1.018372] [] fw_cfg_sysfs_init+0x34/0x61 > > [ 1.018376] [] do_one_initcall+0xb8/0x230 > > [ 1.018379] [] kernel_init_freeable+0x17a/0x219 > > [ 1.018381] [] ? initcall_blacklist+0xb0/0xb0 > > [ 1.018383] [] ? rest_init+0x80/0x80 > > [ 1.018385] [] kernel_init+0xe/0xf0 > > [ 1.018388] [] ret_from_fork+0x58/0x90 > > [ 1.018390] [] ? rest_init+0x80/0x80 > > [ 1.018392] ---[ end trace d00a5b71608a8f59 ]--- > > > > Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1533367 > > Fixes: e90cb816599b ("fw_cfg: do DMA read operation", 2017-11-28) > > CC: Marc-André Lureau > > CC: Michael S. Tsirkin > > Signed-off-by: Peter Xu > > -- > > > > This is based on tree: > > https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git/log/?h=vhost > > > > Please review, thanks. > > > > Signed-off-by: Peter Xu > > The DMA business is confusing, sadly I didn't get much clue what I was > supposed to do. What I can say: > > Tested-by: Marc-André Lureau Thanks for confirming this. > > Should the series be removed from Michael tree and I squash your fix & > send a v10? > > Fwiw, "fw_cfg: write vmcoreinfo details" should also be fixed to > allocate memory (unless your approach fixes that?) Yes, IMHO this patch should also work for writes (though not tested). Thanks, -- Peter Xu