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

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

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.

As an summary it is okay IMO to re-use these host properties.

~ Oleksii