From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45332) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZETzC-000789-0Y for qemu-devel@nongnu.org; Sun, 12 Jul 2015 23:00:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZETz7-00064z-VX for qemu-devel@nongnu.org; Sun, 12 Jul 2015 23:00:53 -0400 Received: from e23smtp06.au.ibm.com ([202.81.31.148]:39889) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZETz7-00064m-8q for qemu-devel@nongnu.org; Sun, 12 Jul 2015 23:00:49 -0400 Received: from /spool/local by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 13 Jul 2015 12:50:41 +1000 Received: from d23relay09.au.ibm.com (d23relay09.au.ibm.com [9.185.63.181]) by d23dlp02.au.ibm.com (Postfix) with ESMTP id 856DB2BB0040 for ; Mon, 13 Jul 2015 12:50:39 +1000 (EST) Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay09.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t6D2oTqb18677962 for ; Mon, 13 Jul 2015 12:50:39 +1000 Received: from d23av01.au.ibm.com (localhost [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t6D2o4F5001801 for ; Mon, 13 Jul 2015 12:50:05 +1000 Message-ID: <55A32743.9040901@linux.vnet.ibm.com> Date: Mon, 13 Jul 2015 10:49:39 +0800 From: zyimin MIME-Version: 1.0 References: <1436334295-6012-1-git-send-email-zyimin@linux.vnet.ibm.com> <1436334295-6012-2-git-send-email-zyimin@linux.vnet.ibm.com> <20150709074824.GA10208@redhat.com> <559E3F20.1070405@linux.vnet.ibm.com> <20150709125556-mutt-send-email-mst@redhat.com> In-Reply-To: <20150709125556-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 1/1] 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, qemu-devel@nongnu.org, agraf@suse.de On 7/9/2015 5:57 PM, Michael S. Tsirkin wrote: > On Thu, Jul 09, 2015 at 05:30:08PM +0800, zyimin wrote: >> >> On 7/9/2015 3:48 PM, Michael S. Tsirkin wrote: >>> On Wed, Jul 08, 2015 at 01:44:55PM +0800, Yi Min Zhao wrote: >>>> @@ -588,9 +606,172 @@ static const TypeInfo s390_pcihost_info = { >>>> } >>>> }; >>>> +static void s390_pci_device_hot_plug(HotplugHandler *hotplug_dev, >>>> + DeviceState *dev, Error **errp) >>>> +{ >>>> + S390PCIBusDevice *zpci = S390_PCI_DEVICE(dev); >>>> + S390PCIBusDevice *tmp; >>>> + S390PCIFacility *f = S390_PCI_FACILITY( >>>> + object_resolve_path(TYPE_S390_PCI_FACILITY, NULL)); >>>> + >>>> + QTAILQ_FOREACH(tmp, &f->zpci_list, next) { >>>> + /* for now, we use fid to sort the list, need to use uid instead >>>> + * when uid is ready. >>> What does ready mean in this context? >> uid is a new feature on s390 arch for pci card management. >> But support of uid on OS level has not been ready. > Does this matter here? I thought it's an arbitrary order - > just making it stable is enough? I think there i sno matter here. Because uid is just for zpci management of firmware and both of fid and uid are unique for all zpci devices attached to one guest. FID maybe change after s390 machine restart. If machine reboot, host will scan PCI devices again and will obtain new FID of every zPCI devices. For guest, it is isolated. > >>>> + */ >>>> + if (tmp->fid > zpci->fid) { >>>> + break; >>>> + } >>>> + } >>>> + >>>> + if (tmp) { >>>> + QTAILQ_INSERT_BEFORE(tmp, zpci, next); >>>> + } else { >>>> + QTAILQ_INSERT_TAIL(&f->zpci_list, zpci, next); >>>> + } >>>> + f->token_valid = false; >>>> +} >>> This still means hotplug will change the index. >>> How about just using an explicit property to set the index? >>> Harder to use but keeps code simple. >>> >> These code were written by Hong Bo. I think he wants to use zpci->fid to >> sort pci cards. >> "index" what you talked is the order of hotplug? right? If it is, I think >> this code actually >> can change the index. > I don't really understand what you are saying. id is how guest looks > up the device, right? it shouldn't change really. For guest, it will use a special instruction to get pci info of all attached pci devices. For example, there are two pci devices which already are attached to the guest. PCI1: fid=1, uid=1 PCI2: fid=3, uid=3 Then, you hotplug a new pci device to the guest: PCI3: fid=2, uid=2 Although PCI2 is at the 3rd position of zpci_list, it will not effect guest looks up the device. Because guest uses fid and fh to get zpci info and do pci operations. I think fid and uid is just the explicit property what you said.