From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGCg6-0007Qr-PG for qemu-devel@nongnu.org; Mon, 15 Jun 2009 09:56:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGCg1-0007Np-TN for qemu-devel@nongnu.org; Mon, 15 Jun 2009 09:56:50 -0400 Received: from [199.232.76.173] (port=46258 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGCg1-0007NU-B8 for qemu-devel@nongnu.org; Mon, 15 Jun 2009 09:56:45 -0400 Received: from mx20.gnu.org ([199.232.41.8]:46933) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MGCg0-0004XC-7z for qemu-devel@nongnu.org; Mon, 15 Jun 2009 09:56:44 -0400 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGCfy-0002M6-Dp for qemu-devel@nongnu.org; Mon, 15 Jun 2009 09:56:43 -0400 Message-ID: <4A36529D.4060200@redhat.com> Date: Mon, 15 Jun 2009 16:54:37 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities] References: <20090610150129.GC28601@redhat.com> <200906101624.30659.paul@codesourcery.com> <20090610174301.GC7416@shareable.org> <20090610182227.GN28601@redhat.com> <20090610192702.GH7416@shareable.org> <1244796209.16425.20.camel@blaa> <4A326B5C.5010501@codemonkey.ws> <1244821292.30522.56.camel@blaa> <4A327E4A.7010300@codemonkey.ws> <1244825303.26769.19.camel@blaa> <20090614095016.GA7560@redhat.com> <4A3617D4.5090405@redhat.com> <4A36424D.3080901@codemonkey.ws> <4A364698.1090402@redhat.com> <4A364A9B.9070001@codemonkey.ws> <4A364E32.4010808@redhat.com> <4A365078.5080209@codemonkey.ws> In-Reply-To: <4A365078.5080209@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Carsten Otte , Rusty Russell , kvm@vger.kernel.org, Mark McLoughlin , Glauber Costa , "Michael S. Tsirkin" , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Blue Swirl , Christian Borntraeger , Paul Brook On 06/15/2009 04:45 PM, Anthony Liguori wrote: > Avi Kivity wrote: >> On 06/15/2009 04:20 PM, Anthony Liguori wrote: >>> It's not at all that simple. SCSI has a hierarchical address >>> mechanism with 0-7 targets but then potentially multiple LUNs per >>> target. Today, we always emulate a single LUN per target but if we >>> ever wanted to support more than 7 disks on a SCSI controller, we >>> would have to add multiple LUN support too. So the current linear >>> unit= parameter is actually pretty broken for SCSI. >> >> Well, another level in the hierarchy, but I don't think it materially >> changes things. > > Depends on whether you expect to say index=0,lun=3 or index=3. If you > mean the later, then it's quite conceivable that each target supports > less than the maximum number of LUNs. This makes things pretty > confusing to the user because they have to know that in the current > implementation, index=0 is valid, index=1 isn't, but index=8 is. I'd object to any implicit addressing rules. If we have to say target=2,lun=7,street=8,city=9,state=99,zip=12345 instead of index=8345345235 so be it. >>> No, I meant drive file=foo.img,bus=3. If that doesn't seem obvious >>> what it should do to you that's because it isn't at all obvious :-) >>> It ends up skipping a predefined number of locations in the drive >>> table. This is pretty broken fundamentally because it assumes >>> controllers always support a fixed number of devices. Nothing >>> really respects bus_id though so in practice, I assume it's almost >>> universally broken. >> >> Isn't the drive table something totally internal? And how does bus= >> relate to it? > > The reality of unit=X,bus=Y,if=Z is that they expand to: > > drive_table_index=Y*max_devs[Z] + X > > Whereas max_devs = {"ide":4, "scsi": 7, *:0} > > How drive_table_index is interpreted is "if" specific. For if=scsi, > each lsi device gets a base drive table index that starts at bus_index > * 7. For virtio, the first empty spot in drive_table results in no > more drives being created. > > It's broken by design. Agreed. Pity that it's exposed to the poor users. -- error compiling committee.c: too many arguments to function