On 23.06.2016 14:35, Jan Kiszka wrote:
On 2016-06-23 13:28, Valentine Sinitsyn wrote:
Hi Jan,
On 23.06.2016 13:53, Jan Kiszka wrote:
On 2016-06-23 11:33, Valentine Sinitsyn wrote:
Hi all,
What is the semantics of system_config->interrupt_limit field?
Am I right that this is a maximum number of distinct interrupt messages
a board is allowed to generate? Or is it an architectural limit for the
number of vectors?
In practice, it is the maximum number of distinct interrupt sources to
expect on Intel systems, used to size the IR table appropriately (on
AMD, they are device-bound, so you shouldn't have a need for this). As
we have no SMMU for ARM yet, I'm not sure if there will be a reuse. If
not, we can make it x86-only.
I'm inclined to have a single shared interrupt table on AMD as well. We
don't have a subpage allocator in Jailhouse (I've sketched one last
night, but it didn't go really well), and handing off page-sized tables
to devices needing only a single IRTE seems to be a waste. So knowing
the size of the table in advance is also convenient.
Ah, you have per-device table references, but they could point to a
single table. Then the limit would be relevant for AMD as well.
But how would you identify / filter the sources then? In contrast to
VT-d IRTEs, you do not seem to have source ID matching with AMD IRTEs,
do you?
That's true. I think I'll store a reverse mapping from bdf to the offset
within single table, much like amd_iommu driver does in the Linux kernel.
Valentine
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
