> > > Not all ram is associated with a device. > > > > Maybe not, but where it is we should be using that information. > > Absolute minimum we should be using the existing qdev address rather than > > inventing a new one. Duplicating this logic inside every device seems > > like a bad idea so I suggest identifying ram blocks by a (name, device) > > pair. For now we can allow a NULL device for system memory. > > I'm not sure if this is what you're after, but what if we change it to > something like: > > + snprintf(name, sizeof(name), "%s.%02x.%x.rom-%s", > + pdev->bus->qbus.name, PCI_SLOT(pdev->devfn), > + PCI_FUNC(pdev->devfn), pdev->qdev.info->name); > > This gives us things like "pci.0.03.0.rom-rtl8139". For pci-assign, we > can expand on the host details, such as: > .. > Giving us "pci.0.04.0.bar0-pci-assign(0000:01:10.0)". Anywhere closer? Not really. This identifier is device and bus independent, which is why I suggested passing the device to qemu_ram_alloc. This can then figure out how to the identify the device. It should probably do this the same way that we identify the saved state for the device. Currently I think this is an arbitrary vmstate name/id, but I expect this to change to a qdev address (e.g. /i440FX-pcihost/pci.0/_addr_04.0"). Paul -- 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
