From nobody Thu May 15 01:10:51 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1512565709250591.0770765644711; Wed, 6 Dec 2017 05:08:29 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3589C5D9E4; Wed, 6 Dec 2017 13:08:28 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 111C25E25F; Wed, 6 Dec 2017 13:08:28 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id CD5DA1800BDF; Wed, 6 Dec 2017 13:08:27 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id vB6D8CRO023409 for ; Wed, 6 Dec 2017 08:08:12 -0500 Received: by smtp.corp.redhat.com (Postfix) id 6F6854D71F; Wed, 6 Dec 2017 13:08:12 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-117-84.phx2.redhat.com [10.3.117.84]) by smtp.corp.redhat.com (Postfix) with ESMTP id 35F42679D5 for ; Wed, 6 Dec 2017 13:08:12 +0000 (UTC) From: John Ferlan To: libvir-list@redhat.com Date: Wed, 6 Dec 2017 08:08:06 -0500 Message-Id: <20171206130806.13619-5-jferlan@redhat.com> In-Reply-To: <20171206130806.13619-1-jferlan@redhat.com> References: <20171206130806.13619-1-jferlan@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH 4/4] conf: Fix generating addresses for SCSI hostdev X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Wed, 06 Dec 2017 13:08:28 +0000 (UTC) X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" https://bugzilla.redhat.com/show_bug.cgi?id=3D1519130 Commit id 'dc692438' reverted the automagic addition of a SCSI controller attempt during virDomainHostdevAssignAddress; however, the logic to determine where to place the next_unit depended upon the "new" controller being added. Without the new controller the the next time through the call for the next SCSI hostdev found would result in the "next_unit" never changing from 0 (zero) and as a result the addition of the device will fail due to being a duplicate unit number of the first with the error message: virDomainDefCheckDuplicateDriveAddresses:$line : unsupported configuration: SCSI host address controller=3D'0' bus=3D'1' target=3D'0' unit=3D'0' in use by another SCSI host device So instead of walking the controller list looking for SCSI controllers, all we can do is "pretend" that they exist and allow other code to create them later as necessary. Signed-off-by: John Ferlan --- src/conf/domain_conf.c | 31 +++++++++++++------------------ 1 file changed, 13 insertions(+), 18 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 61b4a0075..73c6708cf 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -4322,10 +4322,8 @@ virDomainHostdevAssignAddress(virDomainXMLOptionPtr = xmlopt, const virDomainDef *def, virDomainHostdevDefPtr hostdev) { - int next_unit =3D 0; - unsigned controller =3D 0; + int controller =3D 0; unsigned int max_unit; - size_t i; int ret; =20 if (xmlopt->config.features & VIR_DOMAIN_DEF_FEATURE_WIDE_SCSI) @@ -4333,33 +4331,30 @@ virDomainHostdevAssignAddress(virDomainXMLOptionPtr= xmlopt, else max_unit =3D SCSI_NARROW_BUS_MAX_CONT_UNIT; =20 - for (i =3D 0; i < def->ncontrollers; i++) { - if (def->controllers[i]->type !=3D VIR_DOMAIN_CONTROLLER_TYPE_SCSI) - continue; - - controller++; - ret =3D virDomainControllerSCSINextUnit(def, max_unit, - def->controllers[i]->idx); - if (ret >=3D 0) { - next_unit =3D ret; - controller =3D def->controllers[i]->idx; - break; - } - } - /* NB: Do not attempt calling virDomainDefMaybeAddController to * automagically add a "new" controller. Doing so will result in * qemuDomainFindOrCreateSCSIDiskController "finding" the controller * in the domain def list and thus not hotplugging the controller as * well as the hostdev in the event that there are either no SCSI * controllers defined or there was no space on an existing one. + * + * Because we cannot add a controller, then we should not walk the + * defined controllers list in order to find empty space. Doing + * so fails to return the valid next unit number for the 2nd + * hostdev being added to the as yet to be created controller. */ + do { + ret =3D virDomainControllerSCSINextUnit(def, max_unit, controller); + if (ret < 0) + controller++; + } while (ret < 0); + =20 hostdev->info->type =3D VIR_DOMAIN_DEVICE_ADDRESS_TYPE_DRIVE; hostdev->info->addr.drive.controller =3D controller; hostdev->info->addr.drive.bus =3D 0; hostdev->info->addr.drive.target =3D 0; - hostdev->info->addr.drive.unit =3D next_unit; + hostdev->info->addr.drive.unit =3D ret; =20 return 0; } --=20 2.13.6 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list