On Sun, 2015-09-13 at 09:12 +1000, Benjamin Herrenschmidt wrote: > On Sat, 2015-09-12 at 20:37 +0200, Knut Omang wrote: > > As the thread went silent after our conclusions, I have made a > > second > > implementation for the Intel IOMMU according to this alternate > > scheme, > > It keeps the current API and handles the bus number resolution > > lazily > > within the IOMMU implementation, I will post the (single) patch as > > v3 > > of this. > > > > Hopefully this is acceptable and can be leveraged to do a similar > > rework, or be abstracted as generic functionality (?) for the other > > architectures,.. > > Ah sorry, I meant to look at your email in more details and respond > but > it fell through the cracks.
I know how it is.. :-) > I'm happy to have a look at your work and see how it applies to me, > you > can see my powernv code which also supports translation for devices > behind bridges here (but doesn't do as much caching as q35 does): > > https://github.com/ozbenh/qemu/commit/4e0ed1002f98fd97aa7ca3a48c74933 > d0343dd42 Looks conceptually similar - the caching part is probably not that important, it just came natural as it evolved from the original implementation. We are probably so far talking about max a few buses and a few devices per bus, I suppose. I suppose the best then now would be to stick to your suggestion of getting the functionality in and let it mature, then look for any optimization whether structural or performance wise, > Which depends on: > > https://github.com/ozbenh/qemu/commit/facedeba8811985ca20ac3dbad5d07e > 1a10ea9b2 > > (Which I think Michael merged recently, I haven't checked). Yes, I noticed while rebasing. > Cheers, > Ben. Cheers, Knut
