From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48789 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PAgjy-0005UP-FM for qemu-devel@nongnu.org; Tue, 26 Oct 2010 06:26:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PAghC-0004QD-5R for qemu-devel@nongnu.org; Tue, 26 Oct 2010 06:23:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:15008) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PAghB-0004Q9-To for qemu-devel@nongnu.org; Tue, 26 Oct 2010 06:23:58 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o9QANuuR025447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 26 Oct 2010 06:23:56 -0400 Date: Tue, 26 Oct 2010 12:23:54 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] [PATCH] initialize unit id of IDE bus Message-ID: <20101026102354.GN2343@redhat.com> References: <20101024162315.GG2343@redhat.com> <20101025154236.GH2343@redhat.com> <20101025164913.GA31633@redhat.com> <20101025182016.GC877@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:29:49AM +0200, Markus Armbruster wrote: > Gleb Natapov writes: > > > On Mon, Oct 25, 2010 at 08:06:13PM +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); > >> >> > >> >> 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. > >> >> > >> >> Hope I didn't screw this up too badly. > >> > Will check tomorrow if this works, but why not have simple property on > >> > IDEBus that says which one is it? > >> > >> Because nobody has needed it so far? > >> > >> Does the bus care whether it's first or second? > >> > > User that wants to address particular disk cares. > > Define "user". > User is a guest OS. > For users of qemu, the way to address a particular disk (or any qdev > device) is by user-specified ID. > > For users within qemu, there are other ways. > Which ways? > I'm asking whether the bus cares, because IDEBus holds the state of the > bus. If the bus itself doesn't care whether it's primary or secondary, > then this state should not carry that information. > Bus cares because devices on the bus are addressed differently depending on which bus it resides on. > >> > BTW what -device magic should I use to > >> > create secondary disk on second IDE bus? > >> > >> Try -device ide-drive,bus=ide.1,unit=1,drive=... > > Can I > > In qdev, we address buses by ID, just like devices. Unlike device IDs, > which are specified by the user, the bus IDs are auto-generated. The > secondary bus of piix3-ide gets the bus ID "ide.1". Unfortunately those ids are meaningless from outside of qemu. > > We do have usability problems there. There is no way for the user to > specify an ID for a default device, as far as I know. The bus IDs are > defined by the device providing the bus. If it provides none, qdev core > makes one up. This breaks down in corner cases. For instance, with -M > isapc, we get two isa-ide. Each provides an IDE bus without specifying > its ID. qdev core assigns the same name "ide.0" to both. bus=ide.0 > picks the first one (in not-really-specified qtree traversal order). > As far as I can tell, there's no way to address the second one. > This looks like fundamental problem in qdev design. In my case bus names assigned by qdev are useless even when done right though :( > > Can I > > instantiate ide-device on USB bus by doing -device ide-drive,bus=usb? > > -usb -drive if=none,file=tmp.qcow2,id=dr0 \ > -device ide-drive,bus=usb.0,unit=1,drive=dr0 > qemu-system-x86_64: -device ide-drive,bus=usb.0,unit=1,drive=dr0: Device 'ide-drive' can't go on a USB bus -- Gleb.