Re: [RFC XEN PATCH v8 5/5] domctl: Add XEN_DOMCTL_gsi_permission to grant gsi

[Jan Beulich <jbeulich@xxxxxxxx>]

On 05.06.2024 09:04, Chen, Jiqian wrote:
> On 2024/6/5 01:17, Jan Beulich wrote:
>> On 04.06.2024 10:18, Chen, Jiqian wrote:
>>> I tried to get more debug information from my environment. And I attach 
>>> them here, maybe you can find some problems.
>>> acpi_parse_madt_ioapic_entries
>>>     acpi_table_parse_madt(ACPI_MADT_TYPE_INTERRUPT_OVERRIDE, 
>>> acpi_parse_int_src_ovr, MAX_IRQ_SOURCES);
>>>             acpi_parse_int_src_ovr
>>>                     mp_override_legacy_irq
>>>                             only process two entries, irq 0 gsi 2 and irq 9 
>>> gsi 9
>>> There are only two entries whose type is ACPI_MADT_TYPE_INTERRUPT_OVERRIDE 
>>> in MADT table. Is it normal?
>>
>> Yes, that's what you'd typically see (or just one such entry).
> Ok, let me conclude that acpi_parse_int_src_ovr get two entries from MADT 
> table and add them into mp_irqs. They are [irq, gsi][0, 2] and [irq, gsi][9, 
> 9].
> Then in the following function mp_config_acpi_legacy_irqs initializes the 1:1 
> mapping of irq and gsi [0~15 except 2 and 9], and add them into mp_irqs.
> But for high GSIs(>= 16), no mapping processing.
> Right?

On that specific system of yours - yes. In the general case high GSIs
may have entries, too.

> Is it that the Xen hypervisor lacks some handling of high GSIs?

I don't think so. Unless you can point out something?

> For now, if hypervisor gets a high GSIs, it can't be transformed to irq, 
> because there is no mapping between them.

No, in the absence of a source override (note the word "override") the
default identity mapping applies.

Jan