On Fri, Nov 19, 2010 at 06:02:58PM +0100, Markus Armbruster wrote: > "Michael S. Tsirkin" <m...@redhat.com> writes: > > > On Tue, Nov 09, 2010 at 11:41:43AM +0900, Isaku Yamahata wrote: > >> On Mon, Nov 08, 2010 at 06:26:33PM +0200, Michael S. Tsirkin wrote: > >> > Replace bus number with slot numbers of parent bridges up to the root. > >> > This works for root bridge in a compatible way because bus number there > >> > is hard-coded to 0. > >> > IMO nested bridges are broken anyway, no way to be compatible there. > >> > > >> > > >> > Gleb, Markus, I think the following should be sufficient for PCI. What > >> > do you think? Also - do we need to update QMP/monitor to teach them to > >> > work with these paths? > >> > > >> > This is on top of Alex's patch, completely untested. > >> > > >> > > >> > pci: fix device path for devices behind nested bridges > >> > > >> > We were using bus number in the device path, which is clearly > >> > broken as this number is guest-assigned for all devices > >> > except the root. > >> > > >> > Fix by using hierarchical list of slots, walking the path > >> > from root down to device, instead. Add :00 as bus number > >> > so that if there are no nested bridges, this is compatible > >> > with what we have now. > >> > >> This format, Domain:00:Slot:Slot....:Slot.Function, doesn't work > >> because pci-to-pci bridge is pci function. > >> So the format should be > >> Domain:00:Slot.Function:Slot.Function....:Slot.Function > >> > >> thanks, > > > > Hmm, interesting. If we do this we aren't backwards compatible > > though, so maybe we could try using openfirmware paths, just as well. > > Whatever we do, we need to make it work for all (qdevified) devices and > buses. > > It should also be possible to use canonical addressing with device_add & > friends. I.e. permit naming a device by (a unique abbreviation of) its > canonical address in addition to naming it by its user-defined ID. For > instance, something like > > device_del /pci/@1,1 > FWIW openbios allows this kind of abbreviation.
> in addition to > > device_del ID > > Open Firmware is a useful source of inspiration there, but should it > come into conflict with usability, we should let usability win. -- Gleb.