On 23.06.2016 15:03, Jan Kiszka wrote:
On 2016-06-23 13:47, Valentine Sinitsyn wrote:
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.
So you will have one forward table per cell in order to achieve
partitioning? That may work... In Intel, there is a single table for
them all, and source matching is used for partitioning.
Why do we need a forward table per cell? It's indexed with device_id,
which doesn't change, and the device is assigned to one cell at time.
Looks like one table should also work, or am I missing something?
Another (unrelated) detail is we'll want an iommu_add_pci_device()
counterpart for the IOAPIC, as it needs a separate DTE entry on AMD. And
looks like ioapic->id = iommu | bdf logic should be made Intel-specific.
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.
