qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Marc-Andre Lureau <mlureau@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Baoquan He" <bhe@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] fw_cfg: don't use DMA mapping for fw_cfg device
Date: Tue, 16 Jan 2018 14:11:02 +0800	[thread overview]
Message-ID: <20180116061102.GA7031@xz-mi> (raw)
In-Reply-To: <CAMxuvax0N5qf5DN5tkmvSEkVcGXMQzfBAY+MxLqJGEttYQnuKQ@mail.gmail.com>

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 <peterx@redhat.com> 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]  [<ffffffffafcf6b3a>] dump_stack+0x19/0x1b
> > [    1.018334]  [<ffffffffaf68fff8>] __warn+0xd8/0x100
> > [    1.018336]  [<ffffffffaf69007f>] warn_slowpath_fmt+0x5f/0x80
> > [    1.018338]  [<ffffffffafb67329>] fw_cfg_dma_transfer+0x399/0x500
> > [    1.018340]  [<ffffffffafb6753c>] fw_cfg_read_blob+0xac/0x1c0
> > [    1.018342]  [<ffffffffafb67720>] fw_cfg_register_dir_entries+0x80/0x450
> > [    1.018344]  [<ffffffffafb67d02>] fw_cfg_sysfs_probe+0x212/0x3f0
> > [    1.018347]  [<ffffffffafa70352>] platform_drv_probe+0x42/0x110
> > [    1.018350]  [<ffffffffafa6e002>] driver_probe_device+0xc2/0x3e0
> > [    1.018352]  [<ffffffffafa6e3f3>] __driver_attach+0x93/0xa0
> > [    1.018354]  [<ffffffffafa6e360>] ? __device_attach+0x40/0x40
> > [    1.018359]  [<ffffffffafa6bbd3>] bus_for_each_dev+0x73/0xc0
> > [    1.018362]  [<ffffffffafa6d97e>] driver_attach+0x1e/0x20
> > [    1.018364]  [<ffffffffafa6d420>] bus_add_driver+0x200/0x2d0
> > [    1.018366]  [<ffffffffb03c2041>] ? firmware_map_add_early+0x58/0x58
> > [    1.018368]  [<ffffffffafa6ea84>] driver_register+0x64/0xf0
> > [    1.018370]  [<ffffffffafa7013a>] __platform_driver_register+0x4a/0x50
> > [    1.018372]  [<ffffffffb03c2075>] fw_cfg_sysfs_init+0x34/0x61
> > [    1.018376]  [<ffffffffaf602108>] do_one_initcall+0xb8/0x230
> > [    1.018379]  [<ffffffffb036b34a>] kernel_init_freeable+0x17a/0x219
> > [    1.018381]  [<ffffffffb036ab19>] ? initcall_blacklist+0xb0/0xb0
> > [    1.018383]  [<ffffffffafce5b30>] ? rest_init+0x80/0x80
> > [    1.018385]  [<ffffffffafce5b3e>] kernel_init+0xe/0xf0
> > [    1.018388]  [<ffffffffafd08898>] ret_from_fork+0x58/0x90
> > [    1.018390]  [<ffffffffafce5b30>] ? 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 <marcandre.lureau@redhat.com>
> > CC: Michael S. Tsirkin <mst@redhat.com>
> > Signed-off-by: Peter Xu <peterx@redhat.com>
> > --
> >
> > 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 <peterx@redhat.com>
> 
> 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 <marcandre.lureau@redhat.com>

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

      reply	other threads:[~2018-01-16  6:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-15  8:55 [Qemu-devel] [PATCH] fw_cfg: don't use DMA mapping for fw_cfg device Peter Xu
2018-01-15 11:22 ` Marc-Andre Lureau
2018-01-16  6:11   ` Peter Xu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180116061102.GA7031@xz-mi \
    --to=peterx@redhat.com \
    --cc=bhe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcandre.lureau@redhat.com \
    --cc=mlureau@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).