Re: [PATCH v1 10/27] xen/riscv: generate IMSIC DT node for guest domains

[Jan Beulich <jbeulich@xxxxxxxx>]

On 10.04.2026 17:40, Oleksii Kurochko wrote:
> On 4/1/26 5:05 PM, Jan Beulich wrote:
>> On 10.03.2026 18:08, Oleksii Kurochko wrote:
>>> Guests using the IMSIC interrupt controller require a corresponding
>>> Device Tree description. Add support for generating an IMSIC node when
>>> building the guest DT.
>>>
>>> Keep a reference to the host IMSIC DT node and reuse its compatible
>>> property while constructing the guest-visible node.
>>
>> Again raises a migration concern. Presumably a guest would then be able
>> to migrate only to other hosts with the same compatible property.
> 
> Right, but I don't think we can do too much and it is the simplest 
> approach just to migrate to hosts with the same compatible property.
> 
> If you concern is about DTS property then for IMSIC it will be always 
> riscv,imsics according to the RISC-V DT spec. (IIRC, the only other 
> option could be qemu,riscv). Actually, I can just hard code 
> "riscv,imsic" explicitly instead of re-using of host name.
> 
> If your concern is that we will migrate to a host which doesn't support 
> IMSIC at all then we should or (a) don't migrate to such host or (b) 
> provide an emulation of IMSIC. And option (b) would be terrible from at 
> least performance point of view.

That would all be only a secondary concern - in an IMSIC is needed right
now, so be it. My primary concern is with inheriting the host IMSIC's
properties.

>>> +static int __init imsic_set_interrupt_extended_prop(struct domain *d,
>>> +                                                    void *fdt)
>>> +{
>>> +    uint32_t len = 0, pos = 0, cpu, phandle;
>>
>> At least pos and cpu should be of fixed width types.
> 
> I thought that uint32_t is fixed width type, isn't it?

Oh, of course. Problem being: I meant "shouldn't". More generally, see
./CODING_STYLE.

Jan