On Thu, Nov 18, 2010 at 12:18:27PM +0200, Gleb Natapov wrote: > On Wed, Nov 17, 2010 at 09:54:27PM +0000, Blue Swirl wrote: > > 2010/11/16 Gleb Natapov <gleb@xxxxxxxxxx>: > > > On Tue, Nov 16, 2010 at 06:30:19PM +0000, Blue Swirl wrote: > > >> >> Perhaps the FW path should use device class names if no name is specified. > > >> > What do you mean by "device class name". We can do something like this: > > >> > if (dev->child_bus.lh_first) > > >> > return dev->child_bus.lh_first->info->name; > > >> > > > >> > i.e if there is child bus use its bus name as fw name. This will make > > >> > all pci devices to have "pci" as fw name automatically. The problem is > > >> > that theoretically same device can provide different buses. > > >> > > >> I meant PCI class name, like "display" for display controllers, > > >> "network" for NICs etc. > > >> > > > That is what my pci bus related patch is doing already. > > > > > >> >> I'll try Sparc32 to see how this fits there. > > >> > > >> Except bootindex is not implemented for SCSI. > > > Will look into adding it. > > > > Thanks. The bootindex on Sparc32 looks like this: > > bootindex /esp@0000000078800000/disk@1,0 > > /ethernet@ffffffffffffffff/ethernet-phy@0 > > > For arches other then x86 there is a lot of work left to be done :) > For starter exotic sparc buses should get their own get_fw_dev_path() > implementation. > > > I don't think I got Lance setup right. > > > > OF paths for the devices would be: > > /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@1,0 > > /iommu@0,10000000/sbus@0,10001000/ledma@5,8400010/le@5,8c00000 > If qdev hierarchy does not correspond to real HW there is no much we can > do expect for fixing qdev. That's bad. This raises a concern: if these paths expose qdev internals, any attempt to fix this will break migration. > > > > The logic for ESP is that ESP (registers at 0x78800000, slot offset > > 0x880000) is handled by the DMA controller (registers at 0x78400000, > > slot offset 0x840000), they are in a SBus slot #5, and SBus (registers > > at 0x10001000) is in turn handled by IOMMU (registers at 0x10000000). > > Lance should be handled the same way. > > > > This hierarchy is partly known by QEMU because DMA accesses use this > > flow, but not otherwise. There is no concept of SBus slots, DMA talks > > to IOMMU directly. Though in this case both ESP, Lance and their DMA > > controllers are on board devices in a MACIO chip. It may be possible > > to add the hierarchy information at each stage. > > > > It should also be possible for BIOS to determine the device just from > > the physical address if we ignored OF compatibility. > It would be nice to be OF compatible at least at some level. Of course OF > spec is not strict enough to have two different implementations produce > exactly same device path that can be compared by strcpy. Can we apply > the series now? At least for x86 it provides useful paths and work can > be continue for other arches by interested parties. > > -- > Gleb. Something I only now realized is that we commit to never changing the paths for any architecture that supports migration. -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
