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 16:26:09 +0200

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

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

--
                        Gleb.



reply via email to

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