All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Guenter Roeck <linux@roeck-us.net>,
	virtualization@lists.linux-foundation.org
Subject: Re: [PATCH vhost v6 08/11] virtio_ring: introduce virtqueue_dma_dev()
Date: Mon, 10 Apr 2023 02:40:58 -0400	[thread overview]
Message-ID: <20230410024029-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <1681106617.2219903-5-xuanzhuo@linux.alibaba.com>

On Mon, Apr 10, 2023 at 02:03:37PM +0800, Xuan Zhuo wrote:
> On Mon, 10 Apr 2023 13:14:13 +0800, Jason Wang <jasowang@redhat.com> wrote:
> > On Mon, Apr 10, 2023 at 11:48 AM Xuan Zhuo <xuanzhuo@linux.alibaba.com> wrote:
> > >
> > > On Fri, 7 Apr 2023 07:02:34 -0400, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > > On Thu, Apr 06, 2023 at 10:20:09AM -0700, Guenter Roeck wrote:
> > > > > Hi,
> > > > >
> > > > > On Mon, Mar 27, 2023 at 12:05:33PM +0800, Xuan Zhuo wrote:
> > > > > > Added virtqueue_dma_dev() to get DMA device for virtio. Then the
> > > > > > caller can do dma operation in advance. The purpose is to keep memory
> > > > > > mapped across multiple add/get buf operations.
> > > > > >
> > > > > > Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > > > > > Acked-by: Jason Wang <jasowang@redhat.com>
> > > > >
> > > > > On sparc64, this patch results in
> > > > >
> > > > > [    4.364643] Unable to handle kernel NULL pointer dereference
> > > > > [    4.365157] tsk->{mm,active_mm}->context = 0000000000000000
> > > > > [    4.365394] tsk->{mm,active_mm}->pgd = fffff80000402000
> > > > > [    4.365611]               \|/ ____ \|/
> > > > > [    4.365611]               "@'/ .. \`@"
> > > > > [    4.365611]               /_| \__/ |_\
> > > > > [    4.365611]                  \__U_/
> > > > > [    4.366165] swapper/0(1): Oops [#1]
> > > > > [    4.366630] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G                 N 6.3.0-rc5-next-20230405 #1
> > > > > [    4.367121] TSTATE: 0000004411001606 TPC: 00000000004375c0 TNPC: 00000000004375c4 Y: 00000002    Tainted: G                 N
> > > > > [    4.367548] TPC: <dma_4u_supported+0x20/0x40>
> > > > > [    4.368111] g0: 0000000000000000 g1: 0000000001a93a50 g2: 0000000000000000 g3: 0000000001a96170
> > > > > [    4.368439] g4: fffff8000416e9a0 g5: fffff8001dc98000 g6: fffff80004170000 g7: 0000000000000005
> > > > > [    4.368769] o0: 0000000000000000 o1: ffffffffffffffff o2: 0000000000000001 o3: fffff800040b78d8
> > > > > [    4.369095] o4: 0000000000000000 o5: 0000000000000000 sp: fffff80004172d51 ret_pc: 00000000004375ac
> > > > > [    4.369934] RPC: <dma_4u_supported+0xc/0x40>
> > > > > [    4.370160] l0: 0000000000000002 l1: 0000000000000002 l2: 0000000000000000 l3: 00000000ffffffff
> > > > > [    4.370493] l4: 0000000000000001 l5: 000000000119d2b0 l6: fffff8000416e9a0 l7: 00000000018df000
> > > > > [    4.370820] i0: 0000000000000001 i1: ffffffffffffffff i2: fffff80004657758 i3: 000000000125ac00
> > > > > [    4.371145] i4: 0000000002362400 i5: 0000000000000000 i6: fffff80004172e01 i7: 000000000050e288
> > > > > [    4.371473] I7: <dma_set_mask+0x28/0x80>
> > > > > [    4.371683] Call Trace:
> > > > > [    4.371864] [<000000000050e288>] dma_set_mask+0x28/0x80
> > > > > [    4.372123] [<0000000000a83234>] virtio_dev_probe+0x14/0x400
> > > > > [    4.372348] [<0000000000ac7a18>] really_probe+0xb8/0x340
> > > > > [    4.372555] [<0000000000ac7d64>] driver_probe_device+0x24/0x120
> > > > > [    4.372794] [<0000000000ac8010>] __driver_attach+0x90/0x1a0
> > > > > [    4.373012] [<0000000000ac5b4c>] bus_for_each_dev+0x4c/0xa0
> > > > > [    4.373226] [<0000000000ac6d80>] bus_add_driver+0x140/0x1e0
> > > > > [    4.373440] [<0000000000ac8d94>] driver_register+0x74/0x120
> > > > > [    4.373653] [<0000000001b2a690>] virtio_net_driver_init+0x74/0xa8
> > > > > [    4.373886] [<0000000000427ee0>] do_one_initcall+0x60/0x340
> > > > > [    4.374099] [<0000000001b02f50>] kernel_init_freeable+0x1bc/0x228
> > > > > [    4.374330] [<0000000000f37264>] kernel_init+0x18/0x134
> > > > > [    4.374534] [<00000000004060e8>] ret_from_fork+0x1c/0x2c
> > > > > [    4.374738] [<0000000000000000>] 0x0
> > > > > [    4.374981] Disabling lock debugging due to kernel taint
> > > > > [    4.375237] Caller[000000000050e288]: dma_set_mask+0x28/0x80
> > > > > [    4.375477] Caller[0000000000a83234]: virtio_dev_probe+0x14/0x400
> > > > > [    4.375704] Caller[0000000000ac7a18]: really_probe+0xb8/0x340
> > > > > [    4.375916] Caller[0000000000ac7d64]: driver_probe_device+0x24/0x120
> > > > > [    4.376146] Caller[0000000000ac8010]: __driver_attach+0x90/0x1a0
> > > > > [    4.376365] Caller[0000000000ac5b4c]: bus_for_each_dev+0x4c/0xa0
> > > > > [    4.376583] Caller[0000000000ac6d80]: bus_add_driver+0x140/0x1e0
> > > > > [    4.376805] Caller[0000000000ac8d94]: driver_register+0x74/0x120
> > > > > [    4.377025] Caller[0000000001b2a690]: virtio_net_driver_init+0x74/0xa8
> > > > > [    4.377262] Caller[0000000000427ee0]: do_one_initcall+0x60/0x340
> > > > > [    4.377480] Caller[0000000001b02f50]: kernel_init_freeable+0x1bc/0x228
> > > > > [    4.377721] Caller[0000000000f37264]: kernel_init+0x18/0x134
> > > > > [    4.377930] Caller[00000000004060e8]: ret_from_fork+0x1c/0x2c
> > > > > [    4.378140] Caller[0000000000000000]: 0x0
> > > > > [    4.378309] Instruction DUMP:
> > > > > [    4.378339]  80a22000
> > > > > [    4.378556]  12400006
> > > > > [    4.378654]  b0102001
> > > > > [    4.378746] <c2076658>
> > > > > [    4.378838]  b0102000
> > > > > [    4.378930]  80a04019
> > > > > [    4.379022]  b1653001
> > > > > [    4.379115]  81cfe008
> > > > > [    4.379507]  913a2000
> > > > > [    4.379617]
> > > > > [    4.380504] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
> > > > >
> > > > > Reverting it fixes the problem. Bisect log attached.
> > > > >
> > > > > The reason is that dma_supported() calls dma_4u_supported(), which
> > > > > expects that dev->archdata.iommu has been initialized. However,
> > > > > this is not the case for the virtio device. Result is a null pointer
> > > > > dereference in dma_4u_supported().
> > > > >
> > > > > static int dma_4u_supported(struct device *dev, u64 device_mask)
> > > > > {
> > > > >         struct iommu *iommu = dev->archdata.iommu;
> > > > >
> > > > >         if (ali_sound_dma_hack(dev, device_mask))
> > > > >                 return 1;
> > > > >
> > > > >         if (device_mask < iommu->dma_addr_mask)
> > > > >                       ^^^^^^^^^^^^^^^^^^^^ Crash location
> > > > >                 return 0;
> > > > >         return 1;
> > > > > }
> > > > >
> > > > > Guenter
> > > >
> > > > This is from the unconditional call to dma_set_mask_and_coherent, right?
> > >
> > > Maybe not.
> > >
> > > The problem is that the dma_4u_supported() will be called in dma_supported().
> > > The premise of this function is that IOMMU has been initialized.
> > >
> > > We hope to turn virtio dev into a direct dma device by dev->ops is null.
> > >
> > > The first step in DMA frame is obtaining ops. In many cases, get_arch_dma_ops()
> > > returns null. When ops is null, dma frame will use direct dma.
> > >
> > > static inline const struct dma_map_ops *get_dma_ops(struct device *dev)
> > > {
> > >         if (dev->dma_ops)
> > >                 return dev->dma_ops;
> > >         return get_arch_dma_ops();
> > > }
> > >
> > > But rethink, this is unreliable. Some platforms have returned their own ops,
> > > including X86.
> > >
> > > Because the priority of dev->dma_ops is higher than get_arch_dma_ops(), we
> > > should not let dev->dma_ops be null. We should define a set of dma_ops to
> > > actively implement direct dMA.
> >
> > Then this will duplicate with existing DMA API helpers. Could we tweak
> > the sparc or introduce a new flag for the device structure then the
> > DMA API knows it needs to use direct mapping?
> 
> If we add a new flag will better. This is not the problem of sparc, x86 may
> occurs this also.
> 
> Thanks.

Looks like I should drop this from my tree for now while you guys
work out a solution?

> 
> >
> > Adding Christoph for more comments.
> >
> > >
> > >
> > > >
> > > > Xuan Zhuo, I feel there should an explanation in the commit log
> > > > about making this unconditional call. Why are you making it
> > > > in probe?
> > > >
> > > > I note that different virtio transports handle this differently.
> > > > And looking at this more I feel this should maybe be reverted for now:
> > > >
> > > > Your patch does:
> > > >
> > > > @@ -243,6 +244,11 @@ static int virtio_dev_probe(struct device *_d)
> > > >         u64 driver_features;
> > > >         u64 driver_features_legacy;
> > > >
> > > > +       _d->dma_mask = &_d->coherent_dma_mask;
> > > > +       err = dma_set_mask_and_coherent(_d, DMA_BIT_MASK(64));
> > > > +       if (err)
> > > > +               return err;
> > > > +
> > > >         /* We have a driver! */
> > > >
> > > >
> > > > but for example virtio PCI has a 32 bit fallback.
> > > >
> > > > For example Virtio legacy also can't access 64 bit addresses at all,
> > > > so it does:
> > > >
> > > >         rc = dma_set_mask(&pci_dev->dev, DMA_BIT_MASK(64));
> > >
> > > dma_set_mask() will also call dma_supported().
> > >
> > >
> > > >         if (rc) {
> > > >                 rc = dma_set_mask_and_coherent(&pci_dev->dev, DMA_BIT_MASK(32));
> > > >         } else {
> > > >                 /*
> > > >                  * The virtio ring base address is expressed as a 32-bit PFN,
> > > >                  * with a page size of 1 << VIRTIO_PCI_QUEUE_ADDR_SHIFT.
> > > >                  */
> > > >                 dma_set_coherent_mask(&pci_dev->dev,
> > > >                                 DMA_BIT_MASK(32 + VIRTIO_PCI_QUEUE_ADDR_SHIFT));
> > > >         }
> > > >
> > > >
> > > > mmio tries a fallback to 32 bit if 64 bit fails which does not make
> > > > sense to me, but maybe I am wrong.
> > > >
> > > >
> > >
> > > These physical devices have IOMMU, so it is normal, but Virtio Dev does not have
> > > any physical IOMMU, so there are problems. I borrow from VDPA. So I think
> > > there are similar problems with VDPA.
> >
> > Yes.
> >
> > Thanks
> >
> > >
> > >
> > > Thanks.
> > >
> > >
> > > >
> > > >
> > > >
> > > >
> > > > > ---
> > > > > # bad: [8417c8f5007bf4567ccffda850a3157c7d905f67] Add linux-next specific files for 20230405
> > > > > # good: [7e364e56293bb98cae1b55fd835f5991c4e96e7d] Linux 6.3-rc5
> > > > > git bisect start 'HEAD' 'v6.3-rc5'
> > > > > # good: [699c146eb5a03458f29e94cfde4d7dd7a36deeb4] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
> > > > > git bisect good 699c146eb5a03458f29e94cfde4d7dd7a36deeb4
> > > > > # good: [efe74e6476a9f04263288009910f07a26597386f] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt.git
> > > > > git bisect good efe74e6476a9f04263288009910f07a26597386f
> > > > > # good: [24be607eedb226c1627973190a0b65cab39440b9] Merge branch 'char-misc-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
> > > > > git bisect good 24be607eedb226c1627973190a0b65cab39440b9
> > > > > # good: [5213285e3f212cf266c085c1c11041adda2bc63f] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git
> > > > > git bisect good 5213285e3f212cf266c085c1c11041adda2bc63f
> > > > > # bad: [e8f5d7e1787104da5977773ba5b3e1d502fdb9e3] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git
> > > > > git bisect bad e8f5d7e1787104da5977773ba5b3e1d502fdb9e3
> > > > > # bad: [c08b5ad3300122790cef1bf7c1f51c554c778e4d] Merge branch 'gpio/for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git
> > > > > git bisect bad c08b5ad3300122790cef1bf7c1f51c554c778e4d
> > > > > # good: [4ea0c97776bf8c63805eb0f8182d9c20072219d9] gpiolib: Check array_info for NULL only once in gpiod_get_array()
> > > > > git bisect good 4ea0c97776bf8c63805eb0f8182d9c20072219d9
> > > > > # good: [b8e4bb0f05bef8334e689618c75cfed122f3a292] vdpa_sim: use kthread worker
> > > > > git bisect good b8e4bb0f05bef8334e689618c75cfed122f3a292
> > > > > # bad: [ac1fa106f52a3ea2d2718a0de7d532d3d6c03e4e] Merge branch 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git
> > > > > git bisect bad ac1fa106f52a3ea2d2718a0de7d532d3d6c03e4e
> > > > > # good: [56c8cf37fb0800ad66c926eb3d044e50691afa6e] virtio_ring: packed: separate dma codes
> > > > > git bisect good 56c8cf37fb0800ad66c926eb3d044e50691afa6e
> > > > > # good: [f19986b93ab7aa23f76dedf9fd8657f865324f78] virtio_ring: update document for virtqueue_add_*
> > > > > git bisect good f19986b93ab7aa23f76dedf9fd8657f865324f78
> > > > > # bad: [60602b367dc928e2b3d6c1f21df5d05f90e37fa3] virtio_ring: correct the expression of the description of virtqueue_resize()
> > > > > git bisect bad 60602b367dc928e2b3d6c1f21df5d05f90e37fa3
> > > > > # bad: [3a06353479111e1c9e072825bb0d0730e3a0f4e7] virtio_ring: introduce virtqueue_dma_dev()
> > > > > git bisect bad 3a06353479111e1c9e072825bb0d0730e3a0f4e7
> > > > > # first bad commit: [3a06353479111e1c9e072825bb0d0730e3a0f4e7] virtio_ring: introduce virtqueue_dma_dev()
> > > >
> > >
> >

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2023-04-10  6:41 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-27  4:05 [PATCH vhost v6 00/11] virtio core prepares for AF_XDP Xuan Zhuo
2023-03-27  4:05 ` [PATCH vhost v6 01/11] virtio_ring: split: separate dma codes Xuan Zhuo
2023-03-28  6:26   ` Jason Wang
2023-03-27  4:05 ` [PATCH vhost v6 02/11] virtio_ring: packed: " Xuan Zhuo
2023-03-27  4:05 ` [PATCH vhost v6 03/11] virtio_ring: packed-indirect: " Xuan Zhuo
2023-03-27  4:05 ` [PATCH vhost v6 04/11] virtio_ring: split: support premapped Xuan Zhuo
2023-03-28  6:27   ` Jason Wang
2023-03-27  4:05 ` [PATCH vhost v6 05/11] virtio_ring: packed: " Xuan Zhuo
2023-03-28  6:27   ` Jason Wang
2023-03-27  4:05 ` [PATCH vhost v6 06/11] virtio_ring: packed-indirect: " Xuan Zhuo
2023-03-28  6:29   ` Jason Wang
2023-03-27  4:05 ` [PATCH vhost v6 07/11] virtio_ring: update document for virtqueue_add_* Xuan Zhuo
2023-03-28  6:30   ` Jason Wang
2023-03-27  4:05 ` [PATCH vhost v6 08/11] virtio_ring: introduce virtqueue_dma_dev() Xuan Zhuo
2023-04-06 17:20   ` Guenter Roeck
2023-04-07  3:17     ` Xuan Zhuo
2023-04-07 12:34       ` Guenter Roeck
2023-04-07 11:02     ` Michael S. Tsirkin
2023-04-10  3:29       ` Xuan Zhuo
2023-04-10  5:14         ` Jason Wang
2023-04-10  6:03           ` Xuan Zhuo
2023-04-10  6:40             ` Michael S. Tsirkin [this message]
2023-04-10  6:42               ` Xuan Zhuo
2023-04-10 15:27           ` Christoph Hellwig
2023-04-11  1:56             ` Xuan Zhuo
2023-04-11  2:09               ` Jason Wang
2023-04-11  3:31                 ` Christoph Hellwig
2023-04-11  3:56                   ` Jason Wang
2023-04-11  4:09                     ` Christoph Hellwig
2023-04-11  4:54                       ` Jason Wang
2023-04-11  5:14                         ` Christoph Hellwig
2023-04-11  5:19                           ` Jason Wang
2023-04-11  8:55                         ` Gerd Hoffmann
2023-04-11  6:11                     ` Xuan Zhuo
2023-04-11  6:20                       ` Christoph Hellwig
2023-04-11  6:28                         ` Xuan Zhuo
2023-04-11  6:46                           ` Christoph Hellwig
2023-04-11  6:51                             ` Xuan Zhuo
2023-04-11  7:04                               ` Xuan Zhuo
2023-04-12  2:03                           ` Xuan Zhuo
2023-04-12 11:54                             ` Christoph Hellwig
2023-04-11  3:26               ` Christoph Hellwig
2023-04-11  6:23                 ` Xuan Zhuo
2023-04-11  6:30                   ` Christoph Hellwig
2023-04-11  6:33                     ` Xuan Zhuo
2023-04-11  6:45                       ` Christoph Hellwig
2023-04-11  7:23                         ` Xuan Zhuo
2023-04-11 12:16                           ` Christoph Hellwig
2023-04-18  6:18                             ` Xuan Zhuo
2023-04-19  5:10                               ` Christoph Hellwig
2023-04-19  6:16                                 ` Xuan Zhuo
2023-04-11  7:12           ` Xuan Zhuo
2023-04-11  8:59             ` Jason Wang
2023-04-11 12:17             ` Christoph Hellwig
2023-03-27  4:05 ` [PATCH vhost v6 09/11] virtio_ring: correct the expression of the description of virtqueue_resize() Xuan Zhuo
2023-03-27  4:05 ` [PATCH vhost v6 10/11] virtio_ring: separate the logic of reset/enable from virtqueue_resize Xuan Zhuo
2023-03-27  4:05 ` [PATCH vhost v6 11/11] virtio_ring: introduce virtqueue_reset() Xuan Zhuo

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=20230410024029-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux@roeck-us.net \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=xuanzhuo@linux.alibaba.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.