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

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

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, 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.
~ Oleksii