On Tue, Nov 20, 2012 at 10:27:11AM +0100, Alexander Graf wrote: > > On 19.11.2012, at 23:51, David Gibson wrote: > > > On Mon, Nov 19, 2012 at 05:34:12PM +0100, Alexander Graf wrote: > >> > >> On 13.11.2012, at 03:47, David Gibson wrote: > >> > >>> From: Alexey Kardashevskiy <a...@ozlabs.ru> > >>> > >>> In future (with VFIO) we will have multiple PCI host bridges on > >>> pseries. Each one needs a unique LIOBN (IOMMU id). At the moment we > >>> derive these from the pci domain number, but the whole notion of > >>> domain numbers on the qemu side is bogus and in any case they're not > >>> actually uniquely allocated at this point. > >>> > >>> This patch, therefore uses a simple sequence counter to generate > >>> unique LIOBNs for PCI host bridges. > >>> > >>> Signed-off-by: Alexey Kardashevskiy <a...@ozlabs.ru> > >>> Signed-off-by: David Gibson <da...@gibson.dropbear.id.au> > >> > >> I don't really like the idea of having a global variable just > >> because our domain ID generation seems to not work as > >> expected. Michael, any comments here? > > > > Well, the patch I sent which changed domain id generation was > > ignored. In any case, as I said, the whole concept of domain numbers > > Michael?
This is user visible, right? So IMHO we should have the user specify LIOBN through a property, rather than assign what's essentially a random value. For ACPI, domain number can go into _SEG method - this is what linux seems to use to assign domain numbers so if we do this things match. > > makes no sense on the qemu side, so I don't think increasing reliance > > on them by using them here is a good idea. > > > > It would be conceptually nicer to derive the liobn from the buid, but > > that would rely on the buid's being unique in the low 32-bits, which > > is true in practice, but seems risky to rely on. > > Well, there has to be some uniqueness from the guest's POV already, no? > > > Alex
