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? 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.
