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

Re: [PATCH v1 07/17] xen/riscv: introduce vCPU AIA initialization





On 8/13/26 11:47 AM, Jan Beulich wrote:
On 13.08.2026 11:24, Baptiste Le Duc wrote:
--- a/xen/arch/riscv/aia.c
+++ b/xen/arch/riscv/aia.c
@@ -14,6 +14,7 @@
  #include <asm/cpufeature.h>
  #include <asm/csr.h>
  #include <asm/current.h>
+#include <asm/imsic.h>
struct vgein_ctrl {
      unsigned long bmp;
@@ -36,6 +37,35 @@ bool aia_usable(void)
      return _aia_usable;
  }
+void vcpu_aia_init(struct vcpu *v)
+{
+    unsigned int new_vsfile_id;
+    int rc;
+
+    if ( !aia_usable() )
+        return;
+
+    new_vsfile_id = vgein_assign(v);
+
+    /*
+     * vgein_assign() returns 0 when no free h/w guest interrupt file is
+     * available (including GEILEN == 0); imsic_map_guest_file() maps nothing
+     * in that case.
+     */
+    rc = imsic_map_guest_file(v, new_vsfile_id);
+    if ( rc )
+    {
+        /* Can't continue w/o correctly mapped IMSIC interrupt file */
+        domain_crash(v->domain);

The vgein id assigned a few lines up is not released here. The domain is dying
anyway, but the guest interrupt file stays marked in use on that pCPU forever,
since nothing else ever calls vgein_release(). A vgein_release(v,
new_vsfile_id) before the domain_crash() would fix it.

Instead of (or in addition to) doing that here, wouldn't releasing better be 
part
of the normal cleanup path? Whether "instead of" or "in addition to" depends on
the implications of deferring the release. But to guarantee no leak, domain
cleanup will want to either do the release, or have an explicit check that is 
was
done.

I think vgein_release() should be here, as when the IMSIC software interrupt file is supported, it will mean that domain_crash() can generally be dropped (there is no need to call imsic_map_guest_file() for s/w IMSIC interrupt file) and the vCPU can use the software interrupt file instead of killing the domain.

~ Oleksii



 


Rackspace

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