[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 10/26] xen/riscv: implement make_intc_domU_node()





On 5/21/26 3:30 PM, Jan Beulich wrote:
On 08.05.2026 16:43, Oleksii Kurochko wrote:
@@ -46,6 +45,15 @@ struct intc_hw_init_ops {
      int (*init)(void);
  };
+struct vintc_init_ops {
+    /* Create interrupt controller node for domain */
+    int (*make_domu_dt_node)(struct kernel_info *kinfo);
+};
+
+struct vintc {
+    struct vintc_init_ops *init_ops;

Pointer-to-const?

@@ -73,3 +74,13 @@ void intc_route_irq_to_xen(struct irq_desc *desc, unsigned 
int priority)
      intc_set_irq_type(desc, desc->arch.type);
      intc_set_irq_priority(desc, priority);
  }
+
+int __init make_intc_domU_node(struct kernel_info *kinfo)
+{
+    struct vintc *vintc = kinfo->bd.d->arch.vintc;
+
+    if ( intc_hw_ops && vintc->init_ops && vintc->init_ops->make_domu_dt_node )

Why the intc_hw_ops check? The variable isn't otherwise used here.

As to the other two checks: Is it plausible for either of the two pointers
to be NULL? If not, merely ASSERT() or even build upon ...

+        return vintc->init_ops->make_domu_dt_node(kinfo);

... NULL derefs to fault anyway?

Specifically this pointers can't be NULL.

Generally it would be okay to just have have NULL derefs in runtime but there isn't guarantee that some register which will be useful to debug where NULL deref happens will be properly filled. I faced that several times so I prefer to have here ASSERT().

Thanks.

~ Oleksii



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.