qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [PATCH v2 2/2] arm_gicv3_kvm: kvm_dist_get/put: skip the


From: Peter Maydell
Subject: Re: [Qemu-arm] [PATCH v2 2/2] arm_gicv3_kvm: kvm_dist_get/put: skip the registers banked by GICR
Date: Fri, 6 Apr 2018 10:36:24 +0100

On 5 April 2018 at 15:22, Peter Maydell <address@hidden> wrote:
> On 29 March 2018 at 11:54, Peter Maydell <address@hidden> wrote:
>> On 23 March 2018 at 12:08, Peter Maydell <address@hidden> wrote:
>>> On 21 March 2018 at 08:00, Shannon Zhao <address@hidden> wrote:
>>>> On 2018/3/20 19:54, Peter Maydell wrote:
>>>>> Can you still successfully migrate a VM from a QEMU version
>>>>> without this bugfix to one with the bugfix ?
>>>>>
>>>> I've tested this case. I can migrate a VM between these two versions.
>>>
>>> Hmm. Looking at the code I can't see how that would work,
>>> except by accident. Let me see if I understand what's happening
>>> here:
>
>> I was thinking a bit more about how to handle this, and
>> my best idea was:
>>
>> (1) send something in the migration stream that says
>> "I don't have this bug" (version number change?
>> vmstate field that's just a "no bug" flag? subsection
>> with no contents?)
>>
>> (2) on the destination, if the source doesn't tell us
>> it doesn't have this bug, and we are running KVM, then
>> shift all the data in the arrays down to fix it up
>> [Strictly what we want to know is if the source is
>> running KVM, not if the destination is, but I don't
>> know of a way to find that out, and in practice TCG->KVM
>> migrations don't work anyway, so it's not a big deal.]
>
> Shannon, are you planning to look at this for 2.12, or should
> we postpone it to 2.13? (It's not a regression, right? So
> we don't necessarily have to urgently fix it for 2.12.)

On reflection, I think I'd aim for 2.13 for this, since:
 * it's not a regression
 * it doesn't actually affect any of our boards, because
   none of them define enough interrupt lines that they
   would actually be using the top 32 that we fail to migrate
 * getting the migration compat right is a bit tricky and
   will benefit from having the time for careful review and testing

Let me know if I'm wrong with any of those assumptions.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]