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

[Alex Williamson]

On Tue, 2010-10-26 at 16:26 +0200, Gleb Natapov wrote:
> On Tue, Oct 26, 2010 at 08:15:52AM -0600, Alex Williamson wrote:
> > On Tue, 2010-10-26 at 13:20 +0200, Markus Armbruster wrote:
> > > >> 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?
> > 
> > Perhaps going into too much detail, but the idea of get_dev_path() is
> > that it's a recursive call up the device try, where each level adds a
> > string to come up with a unique description.  We currently only have
> > this of PCI because it's device path is obvious, while others are not,
> > particularly ISA.
> > 
> > To start, I'd think IDE could easily implement a get_dev_path(), where
> > the IDE qbus calls up to it's parent bus, then appends IDE channel and
> > slot.  So for a PCI IDE controller, we get something like
> > PCI:0000:00:03.0/piix3-IDE0.master (change this to match qdev info
> > strings, I'm just making it up here).
> > 
> If we will do it like you suggest device path will be meaningless
> outside of qemu internals. I would like get_dev_path() to build device
> path that can be used in a guest to locate the device. In your example
> above piix3-IDE0 does not provide any additional information anyway
> since PCI:0000:00:03.0 already point at a device that can be easily
> identified as piix3-ede0 by looking into PCI config space.
> So for IDE I would like it to be like that:
> address@hidden:00:03.0/address@hidden:1

Yep, I agree, just overly verbose in my example I guess.

> > An ISA IDE controller is harder since ISA doesn't have a bus enumeration
> > mechanism.  IIRC, there we some suggestions to use ioports and/or irqs
> > to define a path on ISA, but not all ISA qdev devices expose these.  So
> > perhaps we'd want something like isa.irq14/piix3-IDE0.master.  Doing ISA
> > correctly probably means standardizing some portion of the qdev info for
> > all the ISA devices.  Thanks,
> Have you looked at my isabus_get_dev_path() patch? It keeps track of
> ioports used by ISA device at ISADevice level.

No I hadn't, great!  It won't be an easy path to parse, but that's
probably more a factor of ISA bus architecture than your decision to use
ioports.  Thanks,

Alex