From: Alex Williamson <alex.williamson@redhat.com>
To: Zhou Jie <zhoujie2011@cn.fujitsu.com>
Cc: fan.chen@easystack.cn, mst@redhat.com, qemu-devel@nongnu.org,
caoj.fnst@cn.fujitsu.com, Chen Fan <chen.fan.fnst@cn.fujitsu.com>,
izumi.taku@jp.fujitsu.com
Subject: Re: [Qemu-devel] [PATCH v8 11/12] vfio: register aer resume notification handler for aer resume
Date: Mon, 20 Jun 2016 10:32:26 -0600 [thread overview]
Message-ID: <20160620103226.0ff61b21@ul30vt.home> (raw)
In-Reply-To: <41b0c187-ade0-182e-46b5-afd3e99f1e36@cn.fujitsu.com>
On Mon, 20 Jun 2016 15:41:03 +0800
Zhou Jie <zhoujie2011@cn.fujitsu.com> wrote:
> ping
>
> On 2016/6/12 10:38, Zhou Jie wrote:
> > Hi, Alex
> >
> >> It seems like we have a number of questions open in the thread with MST
> >> from the previous version, particularly whether we should actually drop
> >> the resume notifier and block the reset in the kernel. The concern
> >> being that it's not very well specified what we can and cannot do
> >> between the error interrupt and the resume interrupt. We'd probably
> >> need some other indicate of whether the host has this capability,
> >> perhaps a flag in vfio_device_info. Appreciate your opinions there.
> >> Thanks,
> >>
> >> Alex
> >
> > Have you had a conclusion with MST?
> >
> > How about the process like following?
> > 1. Detect support for VFIO reset blocking.
> > Maybe use vfio_device_info.
> > 2. Immediately notify the VM on error detected.
> > 3. Invoke ioctl(VFIO_DEVICE_PCI_HOT_RESET).
> > If kernel is doing reset, then block in ioctl.
> >
> > Can I ignore the resume notifier?
> > else
> > Shall ioctl block until after receiving resume notification?
I was really hoping to hear your opinion, or at least some further
discussion of pros and cons rather than simply parroting back my idea.
My current thinking is that a resume notifier to userspace is poorly
defined, it's not clear what the user can and cannot do between an
error notification and the resume notification. One approach to solve
that might be that the kernel internally handles the resume
notifications. Maybe that means blocking the ioctl (interruptible
timeout) until the internal resume occurs, or maybe that means
returning -EAGAIN. Probably implementations of each need to be worked
through to determine which is better. We don't want to add complexity
to the kernel simply to make things easier for userspace, but we also
don't want a poorly specified interface that is difficult for
userspace to use correctly. Thanks,
Alex
next prev parent reply other threads:[~2016-06-20 16:32 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-27 2:12 [Qemu-devel] [PATCH v8 11/12] vfio: register aer resume notification handler for aer resume Zhou Jie
2016-05-27 16:06 ` Alex Williamson
2016-06-12 2:38 ` Zhou Jie
2016-06-20 7:41 ` Zhou Jie
2016-06-20 16:32 ` Alex Williamson [this message]
2016-06-21 2:16 ` Zhou Jie
2016-06-21 3:13 ` Alex Williamson
2016-06-21 12:41 ` Chen Fan
2016-06-21 14:44 ` Alex Williamson
2016-06-22 3:28 ` Zhou Jie
2016-06-22 3:56 ` Alex Williamson
2016-06-22 5:45 ` Zhou Jie
2016-06-22 7:49 ` Zhou Jie
2016-06-22 15:42 ` Alex Williamson
2016-06-25 1:24 ` Zhou Jie
2016-06-27 15:54 ` Alex Williamson
2016-06-28 3:26 ` Zhou Jie
2016-06-28 3:58 ` Alex Williamson
2016-06-28 5:27 ` Zhou Jie
2016-06-28 14:40 ` Alex Williamson
2016-06-29 8:54 ` Zhou Jie
2016-06-29 18:22 ` Alex Williamson
2016-06-30 1:45 ` Zhou Jie
2016-07-03 4:00 ` Zhou Jie
2016-07-05 1:36 ` Zhou Jie
2016-07-05 17:03 ` Alex Williamson
2016-07-06 2:01 ` Zhou Jie
2016-07-07 19:04 ` Alex Williamson
2016-07-08 1:38 ` Zhou Jie
2016-07-08 17:33 ` Alex Williamson
2016-07-10 1:28 ` Zhou Jie
2016-07-11 16:24 ` Alex Williamson
2016-07-12 1:42 ` Zhou Jie
2016-07-12 15:45 ` Alex Williamson
2016-07-13 1:04 ` Zhou Jie
2016-07-13 2:54 ` Alex Williamson
2016-07-13 3:33 ` Zhou Jie
2016-06-22 15:25 ` Alex Williamson
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=20160620103226.0ff61b21@ul30vt.home \
--to=alex.williamson@redhat.com \
--cc=caoj.fnst@cn.fujitsu.com \
--cc=chen.fan.fnst@cn.fujitsu.com \
--cc=fan.chen@easystack.cn \
--cc=izumi.taku@jp.fujitsu.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=zhoujie2011@cn.fujitsu.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).