On Wed, Oct 14, 2015 at 11:46:02AM +0300, Pavel Fedin wrote: > Hello! > > > I'm confused by pci changes. It's all arm specific stuff leaking > > out to pci core. > > But... How else would you implement it? I tried to do this as abstract as > possible. Just pass device pointer to functions which > will use it. Or, would you like to override all these functions for ARM > architecture? That would be a huge code duplication. And, > still, they would need PCI device specifier, which they don't have, and what > patch 0003 takes care about. > > > Maybe it was a mistake to put stream id in struct MemTxAttrs: there's > > still nothing using it. > > It will be used by ITS emulation too. Take a look at RFC, ITS code injects > it into the kernel together with MSI data. Also, i know > that it has something to do with SMMU too, so, if we ever implement ARM SMMU, > we'll likely have to deal with them too. > Presence of device ID pretty well emulates what the hardware does - it just > sends this ID along with PCI transaction. > We will use it as soon as we either: > a) Get kernel API approved > b) Get software GICv3 emulation from Shlomo, then i'll be able to rebase my > old software-emulated ITS on top of that. > > > How about we stick PCIDevice * (or even DeviceState *) there? > > "there" = where? In MemTxAttrs? Would it be good to have 64-bit pointer > instead of 16-bit ID there? It is passed by value, and > current version fits into register even on 32-bit host.
OK, so we could rename stream id to requester id. That at least would make sense at the pci level, and would make it unique per hierarchy. But I suspect all these optimizations break later when we need to support multiple root complex devices. > Kind regards, > Pavel Fedin > Expert Engineer > Samsung Electronics Research center Russia >