On 23.06.2016 15:30, Jan Kiszka wrote:
On 2016-06-23 14:27, Valentine Sinitsyn wrote:
On 23.06.2016 15:19, Jan Kiszka wrote:
On 2016-06-23 14:13, Valentine Sinitsyn wrote:
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?
If all device tables would point to the same interrupt table, all
devices could inject interrupts via any entry in that table, no?
Therefore you need per-cell tables to achieve at least cell-based
partitioning.
I also worried about this. However, iommu_map_interrupt() decides which
index will be programmed into an MSI/IOAPIC reg.
Those registers aren't trustworthy, plus any DMA request of the device
Yes, I was under impression they are. OK, makes sense now, thanks.
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.
