Re: [Qemu-devel] [Qemu-ppc] [PATCH 12/12] pseries: Generate unique LIOBNs for PCI host bridges

["Michael S. Tsirkin" <mst@redhat.com>]

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 <aik@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 <aik@ozlabs.ru>
> >>> Signed-off-by: David Gibson <david@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