Re: [PATCH v1 11/27] xen/riscv: create APLIC DT node for guest domains

[Jan Beulich <jbeulich@xxxxxxxx>]

On 17.04.2026 11:01, Oleksii Kurochko wrote:
> 
> 
> On 4/16/26 1:49 PM, Jan Beulich wrote:
>> On 13.04.2026 10:43, Oleksii Kurochko wrote:
>>> On 4/1/26 5:16 PM, Jan Beulich wrote:
>>>> On 10.03.2026 18:08, Oleksii Kurochko wrote:
>>>>> +    res = fdt_property(fdt, "#interrupt-cells", data, len);
>>>>> +    if ( res )
>>>>> +        return res;
>>>>
>>>> So host properties are again directly handed through to the guest?
>>>
>>> I am not sure that it can be different from what host has.
>>>
>>>> Shouldn't the number of interrupts (aiui that's the "number of cells"
>>>> here) a guest gets be independent from the host it runs one?
>>>
>>> The #interrupt-cells property specifies how many 32-bit values (cells)
>>> are used to encode a single interrupt specifier when referencing this
>>> interrupt controller from another device node.
>>> In this APLIC schema, it's fixed at const: 2, meaning every interrupt
>>> reference requires exactly two cells — typically:
>>>
>>> Cell 1 — the interrupt source number (which of the riscv,num-sources
>>> wired inputs)
>>> Cell 2 — the interrupt type/trigger flags (e.g. edge vs. level, active
>>> high/low)
>>
>> So what if #interrupt-cells is 3 in the DT Xen is handed? If Xen can
>> cope, should that value really also be handed through to guests?
> 
> I would say that it depends on what cell 3 will represent. But likely it 
> will be needed to hand it to the guest.
> 
>>
>>>>> +    regs = dt_get_property(aplic_node, "reg", &len);
>>>>> +    if ( !regs )
>>>>> +    {
>>>>> +        printk("%s: Can't find 'reg' property\n", aplic_node->full_name);
>>>>> +        return -FDT_ERR_XEN(ENOENT);
>>>>> +    }
>>>>> +
>>>>> +    res = fdt_property(fdt, "reg", regs, len);
>>>>> +    if ( res )
>>>>> +        return res;
>>>>> +
>>>>> +    data = dt_get_property(aplic_node, "riscv,num-sources", &len);
>>>>> +    if ( !data )
>>>>> +    {
>>>>> +        printk("%s: Can't find 'riscv,num-sources' property\n",
>>>>> +                aplic_node->full_name);
>>>>> +        return -FDT_ERR_XEN(ENOENT);
>>>>> +    }
>>>>> +
>>>>> +    res = fdt_property(fdt, "riscv,num-sources", data, len);
>>>>> +    if ( res )
>>>>> +        return res;
>>>>
>>>> Or maybe this is the number of interrupts?
>>>
>>> This is the total count of hardware interrupt lines wired into this
>>> APLIC domain.
>>>
>>> It could be independent from the host it runs one but looking at the
>>> possible range [1,1023] for this property if we will put for a guest
>>> lets say 22 but new host support only 20 when we will be in a trouble
>>> anyway.
>>
>> Correct. But if you had some hosts with 1024 and some with 256, how
>> would you bring up a guest on the former to later be able to migrate
>> it to one of the latter when guests inherit the count from the host?
> 
> It will be impossible to do that without emulation,

It's not quite clear to me why this would be.

> so I expect it will 
> be easier to simply forbid migration to such a host.
> 
> Basically, it is just a game of numbers. We could try to estimate how 
> many interrupts are needed for the guest, or for simplicity use some 
> hard-coded number (say 128 or 256, something “pretty small”). Will it 
> resolve the migration issue? Partially yes, but not fully, as there 
> could always be cases where the new host’s number of sources is lower 
> than our hard-coded “small guest value.” So having a smaller value will 
> likely help on average and will allow to support more h/w migration to 
> which could happen, but the migration issue will still be present.

An admin, knowing the capabilities of all hosts in a pool, can suitably
limit guests intended to move among hosts. No migration issue at all.

Jan