From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49889) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZC45A-0008Cx-Ot for qemu-devel@nongnu.org; Mon, 06 Jul 2015 06:57:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZC457-0004sq-H7 for qemu-devel@nongnu.org; Mon, 06 Jul 2015 06:57:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36178) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZC457-0004sf-9u for qemu-devel@nongnu.org; Mon, 06 Jul 2015 06:57:01 -0400 Date: Mon, 6 Jul 2015 13:56:56 +0300 From: "Michael S. Tsirkin" Message-ID: <20150706135503-mutt-send-email-mst@redhat.com> References: <20150701131635-mutt-send-email-mst@redhat.com> <5593D2F9.6010600@linux.vnet.ibm.com> <20150701134925-mutt-send-email-mst@redhat.com> <5593E04C.3080204@linux.vnet.ibm.com> <20150701153151-mutt-send-email-mst@redhat.com> <5594A89E.10805@linux.vnet.ibm.com> <20150702070942-mutt-send-email-mst@redhat.com> <55966D87.1040505@linux.vnet.ibm.com> <20150704202136-mutt-send-email-mst@redhat.com> <5599E2BA.4020601@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5599E2BA.4020601@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH v2 1/1] KVM s390 pci infrastructure modelling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hong Bo Li Cc: cornelia.huck@de.ibm.com, borntraeger@de.ibm.com, sebott@linux.vnet.ibm.com, qemu-devel@nongnu.org, agraf@suse.de On Mon, Jul 06, 2015 at 10:06:50AM +0800, Hong Bo Li wrote: > > > On 7/5/2015 2:25, Michael S. Tsirkin wrote: > >On Fri, Jul 03, 2015 at 07:09:59PM +0800, Hong Bo Li wrote: > >>>But I would like to note that pci device drivers require driver handshake > >>>before device goes away. > >>>IIUC s390 hotplug is immediate, which is a problem. > >>>Maybe doing the change will help make sure device removal is acked > >>>by guest before it happens? > >>> > >>I did some prototype today. If define zpci first, the progress of unplug > >>will get complicated. > >The point is that you don't have to remove the zpci device at all. > >Remove pci device from zpci. > > > >I think the complication you refer to is the guest ack of > >the removal, isn't it? > >It's complicated, but it has a chance to actually work with > >pci device drivers. > > > >This, as opposed to just removing the device whenever host > >tells us to. > > This patch supports the ack in this way: > After unplugging, the guest will do some cleanup work and disable the zpci device. > The "is_unplugged" flag in this patch is used to do this ack. Only after the device > be disabled, we can remove the zpci device from list and do unparent. > > The complication I mean is: > 1. If we define zpci first, the user can unplug a s390 pci device in two ways: > a) unplug the vfio pci device first, unplug the zpci device second. > If the user only tell us to unplug the vfio pci, after the ack, we will > still need to wait for the unplug zpci cmd from user, before that, > we have to maintain a useless zpci in list. > > b) Unplug the zpci device directly. This will cause the unplugging of vfio pci > automatically. Then on s390, we have a different unplug cmd comparing to > other platform. > > 2. If we define vfio pci first, the user can unplug a s390 pci device in two ways: > a) Unplug the zpci first, unplug the vfio pci device second. > We don't need to maintain the extra s390 zpci structure, after ack, we can > remove the zpci from list and do unparent. > b) Unplug the vfio pci directly. This will cause the unplugging of zpci > automatically. Then on s390, we have a same unplug cmd comparing to > other platform. You can do the automatic unplug of zpci in 1 as well, can you not? > The ack of these two methods are the same. > > > >>So I prefer defining vfio pci first. > >>And it looks like the vfio pci is the basic device, if we want this > >>vfio pci to work on s390, we have to define a zpci device to give some > >>additional information to it. > >if vfio connects to the bus internal to zpci, it can get > >things from the bus in a natural way. > > > >If zpci is connected to vfio, it becomes much messier. > > > > For these two ways, the vfio pci both connect to the s390 pci root bus. > And zpci devices connect to the s390-pci-fac-bus, there is no difference. What if you don't specify zpci? Does vfio still work? If no then we have to conclude that vfio is connected through zpci not alongside it. -- MST