On 2/12/19 1:22 AM, David Gibson wrote: > On Fri, Feb 08, 2019 at 08:12:12AM +0100, Cédric Le Goater wrote: >> On 2/8/19 6:36 AM, David Gibson wrote: >>> On Mon, Jan 07, 2019 at 07:39:39PM +0100, Cédric Le Goater wrote: >>>> When the thread interrupt management state is retrieved from the KVM >>>> VCPU, word2 is saved under the QEMU XIVE thread context to print out >>>> the OS CAM line under the QEMU monitor. >>>> >>>> This breaks the migration of a TCG guest (and with KVM when >>>> kernel_irqchip=off) because the matching algorithm of the presenter >>>> relies on the OS CAM value. Fix with an extra reset of the thread >>>> contexts to restore the expected value. >>>> >>>> Signed-off-by: Cédric Le Goater <c...@kaod.org> >>> >>> Why is the CAM value you get from KVM different from the one you >>> expect in qemu? >> >> An NVT base identifier is allocated for each VM at the OPAL level >> and each vCPU getd an increment of this value. It is pushed in the >> OS CAM line when the vCPU is scheduled to run. >> >> KVM XIVE names this identifier a VP id. >> >> The QEMU emulation of XIVE uses a fixed value for the NVT base >> identifier. > > Ah, I see. > > Hmm. Really this highlights why I'm uneasy migrating the whole TCTX > as just a blob of registers, even though only some of them are really > runtime state, and others are machine configuration that can be worked > out separately at the two ends.
This is really a special case : 1. migration kernel_irqchip=on -> kernel_irqchip=off 2. debug info from KVM is squashing TCG state We could ignore the VP id configured by KVM but it seems interesting to retrieve. C.
