kvm PCI assignment & VFIO ramblings
Alex Williamson
alex.williamson at redhat.com
Sat Aug 27 04:04:22 EST 2011
On Thu, 2011-08-25 at 20:05 +0200, Joerg Roedel wrote:
> On Thu, Aug 25, 2011 at 11:20:30AM -0600, Alex Williamson wrote:
> > On Thu, 2011-08-25 at 12:54 +0200, Roedel, Joerg wrote:
>
> > > We need to solve this differently. ARM is starting to use the iommu-api
> > > too and this definitly does not work there. One possible solution might
> > > be to make the iommu-ops per-bus.
> >
> > That sounds good. Is anyone working on it? It seems like it doesn't
> > hurt to use this in the interim, we may just be watching the wrong bus
> > and never add any sysfs group info.
>
> I'll cook something up for RFC over the weekend.
>
> > > Also the return type should not be long but something that fits into
> > > 32bit on all platforms. Since you use -ENODEV, probably s32 is a good
> > > choice.
> >
> > The convenience of using seg|bus|dev|fn was too much to resist, too bad
> > it requires a full 32bits. Maybe I'll change it to:
> > int iommu_device_group(struct device *dev, unsigned int *group)
>
> If we really expect segment numbers that need the full 16 bit then this
> would be the way to go. Otherwise I would prefer returning the group-id
> directly and partition the group-id space for the error values (s32 with
> negative numbers being errors).
It's unlikely to have segments using the top bit, but it would be broken
for an iommu driver to define it's group numbers using pci s:b:d.f if we
don't have that bit available. Ben/David, do PEs have an identifier of
a convenient size? I'd guess any hardware based identifier is going to
use a full unsigned bit width. Thanks,
Alex
More information about the Linuxppc-dev
mailing list