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