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: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH] initialize unit id of IDE bus
Date: Tue, 26 Oct 2010 13:20:47 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

[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.

>> >> [...]
>> >> 
>> >> 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.

>> 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?

>> 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?

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.

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.



reply via email to

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