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 at the right address can "emulate" are real MSI (they are technically identical on the wire). That's the whole point about IR. Jan > And it also decides the > exact interrupt message at this index, and ensures CPUs assigned to > other cells are unreachable for this message. So if IRTE 0x01 posts to > root cell, and it's neighborhood 0x02 posts to some other cell, there > seems to be no way for inmate in that cell to abuse entry 0x01. Is it > correct? > > Valentine > >> >>> >>> 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.
