On Tue, Aug 25, 2026 at 10:55:48AM +0530, Nikhil Kumar Singh wrote:
>
>
> 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.
The OS ring is used by LPARs and KVM guests. The TM_QW3_HV_PHYS and
TM_QW2_HV_POOL are used by hypervisors (PHYP and PowerNV linux).
Since migration concerns only KVM guests and LPARs, handling the OS ring
is enough here.
>
> 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.
>
Yes agree, will add this in the commit message. I'll wait to see if
there are any other comments.
Thanks,
Gautam
