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

[Oleksii Kurochko <oleksii.kurochko@gmail.com>]

On 4/17/26 3:50 PM, Jan Beulich wrote:
> On 17.04.2026 10:10, Oleksii Kurochko wrote:
>> On 4/16/26 1:42 PM, Jan Beulich wrote:
>>> 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.
>> Could we do really something better?
>>
>> At the moment, the following properties are inhereted:
>> node name -> not an issue at all, it is just a name of the node and
>> generally doesn't matter what it is in the matter of DTB generation as
>> phandle number of this node will be used as pointer to this node, not
>> the name. If it would be better I can hard code just "imsic".
>>
>> compatible -> also, not a big issue. According to current DT RISC-V
>> bindings it could be just "riscv,imsic". But then I have the question
>> what if one day someone will come up with own implementation of IMSIC
>> then "riscv,own-imsic" will be in host DTB and so I expect that guest
>> DTB should have it as this h/w expects to use specifically OWN-IMSIC
>> driver. So it seems okay to copy compatible from host DTB. Yes, if
>> migration will happen where just "riscv,imsic" is supported then it
>> can't be easily migrated to such h/w and its okay. But generally I
>> expect that compatible will always riscv,imsic.
>>
>> riscv,num-ids -> generally, it could be any number from [63, 2047], but
>> it seems like there is no any sense if put a value bigger then
>> guest-num-ids=min(riscv,num-ids, riscv,num-guest-ids) for guest as h/w
>> can't support more then that. At the same time I don't see too much
>> sense to tell a guest that it supports less then guest-num-ids. What is
>> the problem to give a guest a maximum that IMSIC could provide? With
>> migration, of course, it will be an issue if new host will support
>> different number of riscv,num-ids but I don't know what we can do better
>> then just avoid migration to such hosts if old-num-ids > new-num-ids
>> without significant performance drop.
> 
> This is exactly why an admin may want to limit what a guest gets to
> see / use.

Would it be better then provide a separate define for riscv, num-ids and 
use it here? Maybe here it makes sense to re-use already provided by DT 
binding property:
   riscv,num-guest-ids:
     $ref: /schemas/types.yaml#/definitions/uint32
     minimum: 63
     maximum: 2047
     description:
       Number of interrupt identities are supported by IMSIC guest 
interrupt
       file. When not specified it is assumed to be same as specified by the
       riscv,num-ids property.
And if riscv,num-guest-ids the use some predefined in define value?

Does it make sense then provide the similar defines for compatible and 
node name or for that properties it would be okay to re-use what host 
DTB IMSIC node provides?

~ Oleksii