Cédric Le Goater <c...@kaod.org> writes:
> On 09/20/2016 11:41 AM, Nikunj A Dadhania wrote:
>> Cédric Le Goater <c...@kaod.org> writes:
>>> On 09/20/2016 10:10 AM, Nikunj A Dadhania wrote:
>>>>>>>>>> -static void ics_reject(ICSState *ics, int nr);
>>>>>>>>>> -static void ics_resend(ICSState *ics, int server);
>>>>>>>>>> -static void ics_eoi(ICSState *ics, int nr);
>>>>>>>>>> +static void ics_reject(ICSState *ics, uint32_t nr)
>>>>>>>>>> +{
>>>>>>>>>> + ICSStateClass *k = ICS_GET_CLASS(ics);
>>>>>>>>>
>>>>>>>>> Shouldn't that be ICS_BASE_GET_CLASS()
>>>>>>>>
>>>>>>>> The class hierarchy is something like this:
>>>>>>>>
>>>>>>>> ICS_BASE -> ICS_SIMPLE -> ICS_KVM
>>>>>>>
>>>>>>> yes. but if we called ics_* with an instance of an ics class which is
>>>>>>> not a ICS_SIMPLE class that will break.
>>>>>>
>>>>>> Correct
>>>>>>
>>>>>>> ICSStateClass is the baseclass, whenever we call methods on a ICSState*
>>>>>>> object, we should use the method defines in ICSStateClass.
>>>>>>
>>>>>> Hmm, in that case I need to initialize base class methods in
>>>>>> instance_init of ics_simple
>>>>>
>>>>> yes but this is done, no ? I see :
>>>>>
>>>>> static void ics_simple_class_init(ObjectClass *klass, void *data)
>>>>> {
>>>>> DeviceClass *dc = DEVICE_CLASS(klass);
>>>>> ICSStateClass *isc = ICS_BASE_CLASS(klass);
>>>>
>>>> Right.
>>>>
>>>> Currently, we have this:
>>>>
>>>> + ICSStateClass *isc = ICS_CLASS(klass);
>>>
>>> oh yes and same in the kvm ICS. The name are bit confusing as we are
>>> introducing SIMPLE but not the associated macros.
>>>
>>> You can check on my 2.8 github branch, I got something working there :
>>>
>>>
>>> https://github.com/legoater/qemu/commit/d0b492707debc7192f0860e2c5fc2daa9fd453ac
>>
>> Cool. :-)
>>
>> Thanks for testing.
>
> I did some tests for pnv, pseries tcg and kvm.
>
> It didn't see any migration issues, yet. Do you have some scenario
> to reproduce the fix you are trying to add ? That's under tcg with
> a e1000 ?
Oh that is pretty complex:
Here is how I was reproducing the issue, it does not reproduce always,
but at least 1 in 3 times, and sometimes when lucky 3 in 3 times as well.
* Start a guest with single cpu, kernel-irqchip=off, e1000 card
* From the guest start a flood ping (ssh to guest)
* From the guest console trigger xmon
* Migrate to the target (localhost)
* Once the vm migrates to the target, exit xmon
* In success case, i get the console, and the flood ping continues
* In case of failure, console does not respond and within few seconds I
get a crash
Regards,
Nikunj
