qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for


From: Gleb Natapov
Subject: Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.
Date: Fri, 5 Nov 2010 17:54:27 +0200

On Fri, Nov 05, 2010 at 03:04:05PM +0100, Markus Armbruster wrote:
[skip]
> >> Passing bus numbers explicitly isn't hard either.  Programmer is free to
> >> pass nonsensical numbers.  For the most common case of one bus, the bus
> >> number parameter is just noise.
> > If programmer makes an error this is a bug that should be fixed.
> >
> >> 
> >> There are two disputed issues here:
> >> 
> >> 1. Whether to pass bus numbers explicitly or not.  I'd prefer not.  But
> >>    I won't insist on it.
> >> 
> >> 2. Whether bus numbers are IDE specific or general.  In my opinion, they
> >>    are general.
> >> 
> > Do we have other cases of device providing two buses in qemu tree now?
> > I prefer to do it only for piix3-ide for now and change it later if
> > this is a common pattern.
> 
> A quick, superficial search finds
> 
> device          buses           function creating them
> corgi-ssp       3 x SSI         corgi_ssp_init()
> evb6965-ssi     2 x SSI         stellaris_ssi_bus_init()
I'll look at those.

> cmd646-ide      2 x IDE         pci_cmd646_ide_initfn()
> piix[34]-ide    2 x IDE         pci_piix_ide_initfn()
> via-ide         2 x IDE         vt82c686b_ide_initfn()
And those are the same IDEBus we already discussing.

> 
> It's even conceivable that one device provides two different kinds of
> buses.  I'd expect sane PCI devices to use separate functions for that,
> but not everything's PCI, and not everything's sane.
> 
Exactly, so we should be as flexible as possible to accommodate insane
HW.

> >> >> Because of that, I believe the concept "bus number" should be a generic
> >> >> qdev concept, not special to IDE buses.
> >> > If you think that other devices may benefit from "bus number" I can
> >> > move it into BusState. Important thing is that "bus number" should
> >> > be determined by bus creator and should be independent from order of
> >> > creation. The thing is other devices may use other means to address
> >> > different buses. For instance system bus may have two PCI domains
> >> > one is addressable via 0x0cf8 IO port another is addressable through
> >> > MMIO address 0xf8000000. "bus number" is meaningless for those two
> >> > buses. Instead one of them will be named address@hidden and another one 
> >> > is
> >> > address@hidden
> >> 
> >> The system bus doesn't "have two PCI domains".  There are *devices*
> >> providing PCI buses on the system bus.
> >> 
> > Correct. Not a good example indeed. I can't think of other device with
> > two buses except piix3_ide.
> >
> >> In your example, there are two such devices on the system bus.  One with
> >> configuration I/O port 0x0cf8, and one with memory-mapped configuration
> >> at 0xf8000000.  Bus number is indeed meaningless, because a bus number
> >> numbers a device's buses, not the system bus's devices!
> >> 
> >> Devices are identified by their address on the parent bus.  The
> >> addressing scheme is specific to the parent bus type.
> >> 
> >> Buses are identified by their bus number within their parent device.
> >> The addressing scheme is always the same: ordinal number.
> >> 
> >> >> > I agree it is conceptually wrong. It is not even needed for unique 
> >> >> > device
> >> >> > path generation. It is only needed to make both IDE buses configurable
> >> >> > from command line in ISA machine. I'll drop it in favor of other 
> >> >> > solution,
> >> >> > but qdev has to rethink how devices should it addressable from command
> >> >> > line. Current way is broken.
> >> >> 
> >> >> I agree it's broken and needs fixing.  I appreciate you trying to fix
> >> >> it, but it indeed looks like it's better to fix it separately.
> >> >> 
> >> > OK.
> >> >
> >> >> >> 
> >> >> >> Perhaps we can treat the non-addressability of -M isapc's second IDE 
> >> >> >> bus
> >> >> >> as a separate problem.
> >> >> >> 
> >> >> > Agree, hence I will not use this patch and will get back to just
> >> >> > recording bus_id. But -M isapc is just a symptom of much more serious
> >> >> > problem in qdev. The way devices addressable there is not well 
> >> >> > defined.
> >> >> > Two devices may have the same device path. Ultimately I think qdev
> >> >> > should use device addresses similar to what I am trying to achieve 
> >> >> > here.
> >> >> > For ISA machine it should automatically generate ids like 
> >> >> > address@hidden
> >> >> > for first isa IDE controller and address@hidden for second one. And 
> >> >> > get
> >> >> > rid of user assigned ids. They are good for nothing and exist only
> >> >> > because qdev developer didn't agree on how to name devices.
> >> >> 
> >> >> Yes, ambigous paths are a well-known problem.  For user-defined devices,
> >> >> users can define the (unique) ID, which provides an unambigous path.
> >> > This is just dropping problem onto a user. Qemu is capable to
> >> > create unique ids by itself. Advantage is that it will work for
> >> > internally create devices and user-defined devices.
> >> 
> >> IDs are a user feature.  The user has full control over them.  If we
> >> created IDs automatically, they could clash with the user's.
> >> 
> > That is why I am saying that it is misfeature. It should have been
> > automatically created for all devices.
> 
> Automatically created IDs tend to suck for human users.
> 
You can mitigate it by allowing user to query existing device paths and
making matching more flexible. For instance if you have only one pci
domain with name ACME,pci it will be enough for user to specify only pci
as path element.

> Yes, the problem could have been avoided with a bit more thought.  Too
> bad.  We'll fix it.
> 
> >> The problem is that our rules what to do when the user didn't assign ID
> >> are broken.  Yes, we should make sure every device has an unambigous
> >> name even then.  More so for devices created automatically.
> >> 
> >> >> But default devices don't have one.  When we have two of identical
> >> >> devices without ID on the same bus, their paths become ambigous.
> >> >> 
> >> >> There has been quite some discussion on "canonical path" on the list,
> >> >> but no consensus.  Ironically, one of the places where we got stuck was
> >> >> ISA.  You cut right through that, so that's progress.  Maybe people
> >> >> aren't looking ;)
> >> > That is funny since the problem was already solved looong time ago. Just
> >> > look at Open Firmware device path. They are capable of addressing all
> >> > devices just fine, ISA devices included. What specific problem you had
> >> > with ISA bus? 
> >> 
> >> Lack of consensus.  I was in favour of using I/O base, just like you do.
> >> There were worries about ISA devices not using any I/O ports.
> > There is a solution for that problem for almost 15 years and we are
> > still looking for consensus on qemu list?! Here is ISA device binding
> > spec for Open Firmware: 
> > http://playground.sun.com/1275/bindings/isa/isa0_4d.ps 
> > If ISA device have no IO ports MMIO is used.
> 
> Precedence should promote consensus, but it can't replace it.  If you
> can push the list to consensus, more power to you.
I do not see disagreement right now :) You are saying you agree. Blue
Swirl asked me to use Open Firmware so I assume he agrees to. So who is
against and what are his arguments?

--
                        Gleb.



reply via email to

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