Re: [Qemu-devel] [PATCH/s390-next 3/3] s390x/flic: migrate ais states

[Halil Pasic]

On 07/13/2017 05:11 PM, Dr. David Alan Gilbert wrote:
> * Christian Borntraeger (address@hidden) wrote:
>> On 07/13/2017 04:49 PM, Dr. David Alan Gilbert wrote:
>>> * Halil Pasic (address@hidden) wrote:
>>>>
>>>>
>>>> On 07/13/2017 02:27 PM, Cornelia Huck wrote:
>>>>>> +static void kvm_flic_ais_pre_save(void *opaque)
>>>>>> +{
>>>>>> +    KVMS390FLICStateMigTmp *tmp = opaque;
>>>>>> +    KVMS390FLICState *flic = tmp->parent;
>>>>>> +    struct kvm_s390_ais_all ais;
>>>>>> +    struct kvm_device_attr attr = {
>>>>>> +        .group = KVM_DEV_FLIC_AISM_ALL,
>>>>>> +        .addr = (uint64_t)&ais,
>>>>>> +        .attr = sizeof(ais),
>>>>>> +    };
>>>>>> +
>>>>>> +    if (ioctl(flic->fd, KVM_GET_DEVICE_ATTR, &attr)) {
>>>>>> +        error_report("Failed to retrieve kvm flic ais states");
>>>>> There's not much else we can do in that case, is there?
>>>>>
>>>>
>>>> I think this is a very good question! The ioctl should not fail
>>>> under any circumstances, but if it does we have a problem.
>>>>
>>>> Carrying on happily (what we do now) means effectively discarding
>>>> ais state. In general just discarding state ain't a good idea.
>>>>
>>>> In particular it might be OK, but the patch should explain that!
>>>>
>>>> Regarding what could/should we do in such a case (instead
>>>> of discarding state and carrying on happily) I don't know, so
>>>> I tend to agree with you regarding 'not much else we can do'.
>>>>
>>>> Adding Dave and Juan. Maybe they can tell.
>>>
>>> I keep meaning to make the pre_save give a return value for failure,
>>> but it hasn't currently got one.
>>
>> Would you accept patches for that?
> 
> Sure.
> 
>>>
>>> You could try something like:
>>>
>>>   qemu_file_set_error(migrate_get_current()->to_dst_file, -EINVAL);

@Dave:
Thanks Dave! I was not aware of that! Had a quick look at the
code, I think qemu_file_set_error would indeed do the right thing.

I would prefer error handling being part of the pre_save interface,
because that would be easier to understand, and would provoke thinking
about these problems.

@Christian:
Would you like to implement 'return value for pre_save'
yourself? I mean, I the meanwhile I'm familiar with the code in question
and I enjoy working with Dave and Juan, so if you aren't interested in
doing it yourself but think it's important enough to get it done, I could
take it too?

@Dave:
There are a couple of questions I'm gonna have to ask/investigate should
it be me doing the 'return value for pre_save' (also notes to myself):

Would you see this error handling via pre_save as a parallel infrastructure
(keep the current qemu_file_set_error mechanism) or would you prefer
things converted? IMHO having a single method would be cleaner, but I
have not looked into this in great detail.

Also the question what is the semantic of qemu_file_set_error arises.
It ain't documented and I would intuitively suspect that it's rather
about the 'file' (that is transport) than the whole migration.



>>>
>>>   I *think* the migration code should spot that before it finishes
>>> but it might carry on for a little while before it does.
>>
>> I will keep this patch as is, since this is one of the "should not happen"
>> cases.

@Christian
I'm OK with it, because knowing the kernel code behind the ioctl
this is really unlikely and even if it should happen the risks involved
are rather limited. But I would be much happier if all such
cases would result in refusing migration.

Regards,
Halil