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

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 4/17/26 3:53 PM, Jan Beulich wrote:
> 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.
if migration happens from the host with 256 to the host with 1024 the 
some interrupt remapping/multiplixing might be needed. But I am not 
consider this as a good option...
> > 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.
... this one option is much better. I will introduce define for now in 
vaplic.h header or maybe just inside this function to hard-code this 
amount of interrupts supported by guest vAPLIC for now.
But in future it make sense to introduce property in host APLIC node 
something like riscv,num-guest-sources as IMSIC has for interrupt 
identites (riscv,num-guest-ids).
~ Oleksii