From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40526) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFk1u-0002XW-P6 for qemu-devel@nongnu.org; Wed, 22 Jun 2016 11:25:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFk1q-0004Su-OL for qemu-devel@nongnu.org; Wed, 22 Jun 2016 11:25:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39547) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFk1q-0004Sp-Hw for qemu-devel@nongnu.org; Wed, 22 Jun 2016 11:25:22 -0400 Date: Wed, 22 Jun 2016 09:25:26 -0600 From: Alex Williamson Message-ID: <20160622092526.14c03216@t450s.home> In-Reply-To: <113474d2-8408-db49-e7ef-8c6b736af866@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> <20160620103226.0ff61b21@ul30vt.home> <20160620211306.66a6b249@t450s.home> <576935FC.1080503@easystack.cn> <20160621084443.330f932d@t450s.home> <20160621215626.71c99582@t450s.home> <113474d2-8408-db49-e7ef-8c6b736af866@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: Chen Fan , Chen Fan , izumi.taku@jp.fujitsu.com, caoj.fnst@cn.fujitsu.com, qemu-devel@nongnu.org, mst@redhat.com On Wed, 22 Jun 2016 13:45:10 +0800 Zhou Jie 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