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. > > 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. Sure, I'm open for refactoring proposals. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux -- 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.
