From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35348) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF27l-0000DA-51 for qemu-devel@nongnu.org; Mon, 20 Jun 2016 12:32:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bF27g-0005UT-RZ for qemu-devel@nongnu.org; Mon, 20 Jun 2016 12:32:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60414) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF27g-0005UN-La for qemu-devel@nongnu.org; Mon, 20 Jun 2016 12:32:28 -0400 Date: Mon, 20 Jun 2016 10:32:26 -0600 From: Alex Williamson Message-ID: <20160620103226.0ff61b21@ul30vt.home> In-Reply-To: <41b0c187-ade0-182e-46b5-afd3e99f1e36@cn.fujitsu.com> References: <1464315131-25834-1-git-send-email-zhoujie2011@cn.fujitsu.com> <20160527100655.60db8206@t450s.home> <30d1cd95-7f67-29cf-c55e-0565364d89ff@cn.fujitsu.com> <41b0c187-ade0-182e-46b5-afd3e99f1e36@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v8 11/12] vfio: register aer resume notification handler for aer resume List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Zhou Jie Cc: fan.chen@easystack.cn, mst@redhat.com, qemu-devel@nongnu.org, caoj.fnst@cn.fujitsu.com, Chen Fan , izumi.taku@jp.fujitsu.com On Mon, 20 Jun 2016 15:41:03 +0800 Zhou Jie 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