From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48213) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZC5ET-0003EB-Tp for qemu-devel@nongnu.org; Mon, 06 Jul 2015 08:10:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZC5EO-0000Na-SU for qemu-devel@nongnu.org; Mon, 06 Jul 2015 08:10:45 -0400 Received: from e23smtp05.au.ibm.com ([202.81.31.147]:34417) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZC5EO-0000Mc-AJ for qemu-devel@nongnu.org; Mon, 06 Jul 2015 08:10:40 -0400 Received: from /spool/local by e23smtp05.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 6 Jul 2015 22:10:36 +1000 Received: from d23relay06.au.ibm.com (d23relay06.au.ibm.com [9.185.63.219]) by d23dlp02.au.ibm.com (Postfix) with ESMTP id F128C2BB003F for ; Mon, 6 Jul 2015 22:10:34 +1000 (EST) Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay06.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t66CARfI065848 for ; Mon, 6 Jul 2015 22:10:35 +1000 Received: from d23av04.au.ibm.com (localhost [127.0.0.1]) by d23av04.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t66CA2mZ007980 for ; Mon, 6 Jul 2015 22:10:02 +1000 Message-ID: <559A6FFE.3060404@linux.vnet.ibm.com> Date: Mon, 06 Jul 2015 20:09:34 +0800 From: Hong Bo Li MIME-Version: 1.0 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> <20150706135503-mutt-send-email-mst@redhat.com> In-Reply-To: <20150706135503-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: "Michael S. Tsirkin" Cc: cornelia.huck@de.ibm.com, borntraeger@de.ibm.com, sebott@linux.vnet.ibm.com, qemu-devel@nongnu.org, agraf@suse.de On 7/6/2015 18:56, Michael S. Tsirkin wrote: > 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? ok, got your point, will make a patch to verify that. Thank you! > >> 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. >