From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48689 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PAglg-0005Ty-JX for qemu-devel@nongnu.org; Tue, 26 Oct 2010 06:28:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PAgZM-00022j-8d for qemu-devel@nongnu.org; Tue, 26 Oct 2010 06:15:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62592) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PAgZL-00022V-UU for qemu-devel@nongnu.org; Tue, 26 Oct 2010 06:15:52 -0400 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o9QAFo5T030960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 26 Oct 2010 06:15:51 -0400 Date: Tue, 26 Oct 2010 12:15:49 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] [PATCH] initialize unit id of IDE bus Message-ID: <20101026101549.GM2343@redhat.com> References: <20101024162315.GG2343@redhat.com> <20101025154236.GH2343@redhat.com> <20101026072843.GK2343@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org On Tue, Oct 26, 2010 at 11:14:20AM +0200, Markus Armbruster wrote: > Gleb Natapov writes: > > > On Mon, Oct 25, 2010 at 06:22:12PM +0200, Markus Armbruster wrote: > >> Gleb Natapov writes: > >> > >> > On Mon, Oct 25, 2010 at 04:29:35PM +0200, Markus Armbruster wrote: > >> >> Gleb Natapov writes: > >> >> > >> >> > Without this patch both buses on PIIX3_IDE device have the same unit id. > >> >> > >> >> Are you sure that's wrong? > >> >> > >> > So how do I know which bus is it on PIIX3_IDE? > >> [...] > >> > >> Let me try to explain the IDE pointer thicket. > >> > >> piix3-ide provides two IDE buses. pci_piix_ide_initfn() stores them in > >> PCIIDEState member IDEBus bus[2]. Technically redundant, because qdev > >> stores child buses in dev.qdev.child_bus. > >> > >> IDEBus points back: qbus.parent. > >> > >> Up to two IDE devices can sit on each IDE bus. The first one uses > >> IDEBus members master and ifs[0], the second one uses slave and ifs[1]. > >> > >> ifs[i].bus points back to the IDE bus. > >> > >> {master,slave}.qdev.parent_bus point back to the IDE bus. > >> > >> Say you got an IDEDevice and want to know which to which of the two > >> buses it's connected. Let's call it d. > >> > >> d->qdev.parent_bus is the BusState. > >> > >> Upcast to IDEBus: b = DO_UPCAST(IDEBus, qbus, d->qdev.parent_bus). > >> > >> b->qbus.parent is the IDE controller. > >> > >> Upcast to PCIIDEState: c = DO_UPCAST(PCIIDEState, dev, n->qbus.parent); > >> > > This will not work if IDEBus sits on ISA bus. Any other ideas? > > > >> If c->bus[0] == b, it's on the first bus. > >> > >> Else it must be on the second bus, i.e. c->bus[1] == b. > > Well, you asked for piix3-ide specifically :) > No I didn't. > isa-ide provides just one IDE bus. Thus we have two isa-ide devices. > To find them, you need to walk the ISA devices. Our PCish machines have > just one ISA bus, and it's called "isa.0". You could try > > bus = qbus_find("isa.0"); > QLIST_FOREACH(dev, &bus->children, sibling) { > // examine dev > // it's safe to upcast dev to ISADevice > } > > Perhaps best to have some means in qdev.h to iterate over a bus like > that. > > If dev->info->name is "isa-ide", you found one of the controllers. > When I am on IDEBus level I shouldn't care what bus it resides on to figure out its properties. The things you describe here just show qdev failure to provide reasonable device abstraction for IDEBus. > How to tell whether it's primary or secondary? Primary uses I/O ports > 0x1f0..0x1ff,0x3f0..0x3ff and IRQ 14. IRQ could be easier to check, > because it should be right in ISADevice member isairq[0]. > Alternatively, upcast to ISAIDEState and check members iobase or isairq. Again idebus_dev_path() should not care about what device IDEBus resides on. > > > Hmm, there's a way that doesn't require special-casing the IDE > controller devices: find the IDEBus as above. Then check the IRQ# > b->irq->n: 14 is primary, 15 is secondary. Instead of this horrible hack (which may work, but only for PC), why not add bus_id to IDEBus and be done with it. I already have the patch. -- Gleb.