On Mon, 20 Jun 2016 15:41:03 +0800 Zhou Jie <zhoujie2...@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
