On 24/08/26 12:33, Gautam Menghani wrote:


Hi Gautam,

I was going through the implementation and had a small doubt regarding the scope of the fix for the TIMA rings. I can see that we are explicitly reading and setting the PIPR for TM_QW1_OS:

+    } else {
+        uint8_t pipr = tctx->regs[TM_QW1_OS + TM_PIPR];
+        xive_tctx_pipr_set(tctx, TM_QW1_OS, pipr, 0);
      }

I guess vmstate_xive_tctx_post_load is a shared device code, I was wondering what happens in the case of the other rings? Should we also force a re-evaluation for TM_QW3_HV_PHYS or TM_QW2_HV_POOL to avoid similar lockups in those configurations? Or is this issue strictly coming only in the OS ring in practical scenarios? Please let me know your thoughts on this.

Also, one minor suggestion. Since this logic is going inside the else block of if (kvm_irqchip_in_kernel()), I feel it would be better if we can add a line in the commit message mentioning that this specifically fixes state restoration for environments relying on QEMU's emulated XIVE.

Thanks
~ Nikhil

Reply via email to