|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v1 10/27] xen/riscv: generate IMSIC DT node for guest domains
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
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |