From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: "Jason Wang" <jasowang@redhat.com>,
"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
virtualization@lists.linux.dev, linux-kernel@vger.kernel.org,
"Hongyu Ning" <hongyu.ning@linux.intel.com>
Subject: Re: [PATCH] virtio: Remove virtio devices on device_shutdown()
Date: Thu, 8 Aug 2024 11:03:30 -0400 [thread overview]
Message-ID: <20240808105006-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <yknu4iege3drk6t2x7pvm2l2cocg4r5qk5jzmboej6dqk5ym2z@g4clogtuuibe>
On Thu, Aug 08, 2024 at 04:15:25PM +0300, Kirill A. Shutemov wrote:
> On Thu, Aug 08, 2024 at 08:10:34AM -0400, Michael S. Tsirkin wrote:
> > On Thu, Aug 08, 2024 at 10:51:41AM +0300, Kirill A. Shutemov wrote:
> > > Hongyu reported a hang on kexec in a VM. QEMU reported invalid memory
> > > accesses during the hang.
> > >
> > > Invalid read at addr 0x102877002, size 2, region '(null)', reason: rejected
> > > Invalid write at addr 0x102877A44, size 2, region '(null)', reason: rejected
> > > ...
> > >
> > > It was traced down to virtio-console. Kexec works fine if virtio-console
> > > is not in use.
> >
> > virtio is not doing a lot of 16 bit reads.
> > Are these the reads:
> >
> > virtio_cread(vdev, struct virtio_console_config, cols, &cols);
> > virtio_cread(vdev, struct virtio_console_config, rows, &rows);
> >
> > ?
> >
> > write is a bit puzzling too. This one?
> >
> > bool vp_notify(struct virtqueue *vq)
> > {
> > /* we write the queue's selector into the notification register to
> > * signal the other end */
> > iowrite16(vq->index, (void __iomem *)vq->priv);
> > return true;
> > }
>
> Given that we are talking about console issue, any suggestion on how to
> check?
If you do lspci -v on the device, we'll know where the BARs are,
and can compare to 0x102877002, 0x102877A44.
> > >
> > > Looks like virtio-console continues to write to the MMIO even after
> > > underlying virtio-pci device is removed.
> >
> > You mention both MMIO and pci, I am confused.
>
> By MMIO, I mean accesses to PCI BARs. But it is only my *guess* on the
> situation, I have limited knowledge of the area. I am not drivers guy.
>
> > Removed by what? In what sense?
>
> So device_shutdown() iterates over all device and we hit the problem when
> we get to virtio-pci devices and call pci_device_shutdown on them.
Hmm that clears bus master. So maybe what we see is actually
device trying to do DMA and failing? We'll need to know where do
these addresses are on your system.
> I *think* PCI BAR (or something else?) becomes unavailable after that but
> it is still accessed.
>
> > >
> > > The problem can be mitigated by removing all virtio devices on virtio
> > > bus shutdown.
> > >
> > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> > > Reported-by: Hongyu Ning <hongyu.ning@linux.intel.com>
> >
> > A bit worried about doing so much activity on shutdown,
> > and for all devices, too. I'd like to understand what
> > is going on a bit better - could be a symptom of
> > a bigger problem (e.g. missing handling for suprise
> > removal?).
>
> I probably should have marked the patch as RFC. The patch was intended to
> start conversation. I am not sure it is correct. This patch just happened
> to work in our setup.
>
> --
> Kiryl Shutsemau / Kirill A. Shutemov
next prev parent reply other threads:[~2024-08-08 15:03 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-08 7:51 [PATCH] virtio: Remove virtio devices on device_shutdown() Kirill A. Shutemov
2024-08-08 11:37 ` Jiri Pirko
2024-08-08 12:11 ` Kirill A. Shutemov
2024-08-08 15:28 ` Jiri Pirko
2024-08-08 12:10 ` Michael S. Tsirkin
2024-08-08 13:15 ` Kirill A. Shutemov
2024-08-08 15:03 ` Michael S. Tsirkin [this message]
2024-08-08 15:28 ` Kirill A. Shutemov
2024-11-04 10:22 ` Kirill A. Shutemov
2025-01-31 9:53 ` Eric Auger
2025-01-31 11:55 ` Michael S. Tsirkin
2025-02-03 14:48 ` Michael S. Tsirkin
2025-02-04 11:46 ` Eric Auger
2025-02-06 8:59 ` Eric Auger
2025-02-06 10:04 ` Kirill A. Shutemov
2025-02-06 16:27 ` Eric Auger
2025-02-14 7:21 ` Ning, Hongyu
2025-02-14 7:56 ` Eric Auger
2025-02-14 12:16 ` Michael S. Tsirkin
2025-02-17 3:29 ` Jason Wang
2025-02-17 7:49 ` Ning, Hongyu
2025-02-17 9:25 ` Eric Auger
2025-02-17 16:59 ` Eric Auger
2025-02-17 23:20 ` Michael S. Tsirkin
2025-02-17 23:57 ` Ning, Hongyu
2025-02-18 0:12 ` Michael S. Tsirkin
2025-02-18 1:49 ` Ning, Hongyu
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=20240808105006-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=eperezma@redhat.com \
--cc=hongyu.ning@linux.intel.com \
--cc=jasowang@redhat.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=virtualization@lists.linux.dev \
--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 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).