[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [PATCH 06/13] spapr/xive: fix migration of the XiveTCTX u
From: |
Cédric Le Goater |
Subject: |
Re: [Qemu-ppc] [PATCH 06/13] spapr/xive: fix migration of the XiveTCTX under TCG |
Date: |
Tue, 12 Feb 2019 07:58:28 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 |
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 <address@hidden>
>>>
>>> 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.