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

[Alex Williamson <alex.williamson@redhat.com>]

On Wed, 22 Jun 2016 13:45:10 +0800
Zhou Jie <zhoujie2011@cn.fujitsu.com> wrote:

> Hi Alex,
> 
> >>
> >> In vfio I have some questions.
> >> 1. How can I disable the access by mmap?
> >>     We can disable all access to vfio fd by returning a EAGAIN error
> >>     if user try to access it during the reset period until the host
> >>     reset finished.
> >>     But about the bar region which is maped by vfio_pci_mmap.
> >>     How can I disable it in vfio driver?
> >>     Even there is a way to do it,
> >>     how about the complexity to recovery the mmap?  
> >
> > That's exactly the "sticky point" I refer to above, you'd need to
> > solve that problem.  MST would probably still argue that we don't need
> > to disable all those interfaces, a userspace driver can already do
> > things like disable mmio space and then attempt to read from the mmio
> > space of the device.  
> You said we should not depend on user to protect the device
>   be accessed during the reset period.
> 
> > So maybe the problem can be simplified to
> > non-device specific interfaces, like config space access plus ioctls.  
> I don't understand what's your mean.

I was trying to distinguish between state we control and state the
guest driver owns.  When the guest driver is reading and writing to
device apertures, that's opaque to us.  However when we're doing things
like manipulating interrupts or issuing a reset or even interacting
with partially virtualized config space, that's device state that we're
directly involved with.  So it seems like we have some ability, perhaps
even responsibility to make those work around the error event.  That's
the distinction I'm trying to make. Thanks,

Alex