On Wed, Oct 14, 2015 at 02:49:14PM +0300, Pavel Fedin wrote:
> Hello!
>
> > 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.
>
> Yes, we can, i'm fine with the rename. Additionally, "requester ID" is t
Hello!
> 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.
Yes, we can, i'm fine with the rename. Additionally, "requester ID" is the
official term used in GICv3 architecture manual. When i
implemented i
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 whi
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
On Wed, Oct 14, 2015 at 10:53:14AM +0300, Pavel Fedin wrote:
> On ARM architecture ITS (Interrupt Translation Service), additionally to
> normal MSI data, uses also side-band device IDs. This series prepares the
> infrastructure to handling them.
>
> This small series is actually an extraction fro
On ARM architecture ITS (Interrupt Translation Service), additionally to
normal MSI data, uses also side-band device IDs. This series prepares the
infrastructure to handling them.
This small series is actually an extraction from vITS support RFC
(https://lists.gnu.org/archive/html/qemu-devel/2015-
