qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v8 11/12] vfio: register aer resume notification


From: Alex Williamson
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

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]