qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] initialize unit id of IDE bus


From: Gleb Natapov
Subject: Re: [Qemu-devel] [PATCH] initialize unit id of IDE bus
Date: Tue, 26 Oct 2010 14:12:25 +0200

On Tue, Oct 26, 2010 at 01:20:47PM +0200, Markus Armbruster wrote:
> [Note cc: Alex]
> 
> Gleb Natapov <address@hidden> writes:
> 
> > On Tue, Oct 26, 2010 at 11:14:20AM +0200, Markus Armbruster wrote:
> >> Gleb Natapov <address@hidden> writes:
> >> 
> >> > On Mon, Oct 25, 2010 at 06:22:12PM +0200, Markus Armbruster wrote:
> >> >> Gleb Natapov <address@hidden> writes:
> >> >> 
> >> >> > On Mon, Oct 25, 2010 at 04:29:35PM +0200, Markus Armbruster wrote:
> >> >> >> Gleb Natapov <address@hidden> 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?
> 
> Here's where you ask about piix3-ide specifically.
> 
Because with ISA there is only one, so default value of zero is good
enough.

> >> >> [...]
> >> >> 
> >> >> 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.
> 
> See above.
> 
You take things out of context in individual mails and in a context of
patch series. Are you doing it for the sake of arguing?

> >> 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.
> 
> We really need to define what qbus's get_dev_path() callback is supposed
> to do before we continue.  Alex, you created it.  What's your take on
> its semantics?
It exist only for PCI device and there it gives device address on a PCI
bus in a way that can be mapped back to individual device give only a
string returned by the callback. Combined with the callback name I would
guess that this is its semantics.

> 
> >> 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.
> 
> How's that bus_id defined?
How is PCI domain number defined?

> 
> A disk on an IDE bus has no idea whether its the first or the 77th IDE
> bus in the system.  It only knows whether it's master or slave on this
> bus.  Likewise, the IDE controller doesn't know about other IDE buses in
> the system.  It only knows that it provides N IDE buses.  It doesn't
> know whether they are #1..#N globally.
That doesn't mean you do not enumerate them. Each one of them use
different resources. So they are not the same. If they are not the same
you need to distinguish them. On ISA it is done by ISA bus address
IDEBus resides on. On PCI they reside on the same PCI address.

> 
> A particular system architecture may order its IDE buses and thus assign
> global numbers by convention.  For instance, the PC architecture has a
> primary and a secondary IDE controller, using well-known ISA resources.
And other architecture may have PCI card with to IDE controllers that do
not use well-know ISA resources, but use whatever resources guest OS
configured via PCI bars, but you still what to distinguish them. SCSI
has LUN for instance.

--
                        Gleb.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]