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

[Halil Pasic]

On 07/13/2017 03:10 PM, Cornelia Huck wrote:
> On Thu, 13 Jul 2017 15:02:08 +0200
> Christian Borntraeger <address@hidden> wrote:
> 
>> On 07/13/2017 02:27 PM, Cornelia Huck wrote:
>>> On Thu, 13 Jul 2017 12:40:29 +0200
>>> Christian Borntraeger <address@hidden> wrote:
>>>   
>>>> From: Yi Min Zhao <address@hidden>
>>>>
>>>> During migration we should transfer ais states to the target guest.
>>>> This patch introduces a subsection to kvm_s390_flic_vmstate and new
>>>> vmsd for qemu_flic. The ais states need to be migrated only when
>>>> ais is supported.
>>>>
>>>> Signed-off-by: Yi Min Zhao <address@hidden>
>>>> Signed-off-by: Christian Borntraeger <address@hidden>
>>>> ---
>>>>  hw/intc/s390_flic.c          | 20 ++++++++++++
>>>>  hw/intc/s390_flic_kvm.c      | 75 
>>>> ++++++++++++++++++++++++++++++++++++++++++++
>>>>  include/hw/s390x/s390_flic.h |  1 +
>>>>  3 files changed, 96 insertions(+)
> 
>>>> +static int kvm_flic_ais_post_load(void *opaque, int version_id)
>>>> +{
>>>> +    KVMS390FLICStateMigTmp *tmp = opaque;
>>>> +    KVMS390FLICState *flic = tmp->parent;
>>>> +    struct kvm_s390_ais_all ais = {
>>>> +        .simm = tmp->simm,
>>>> +        .nimm = tmp->nimm,
>>>> +    };
>>>> +    struct kvm_device_attr attr = {
>>>> +        .group = KVM_DEV_FLIC_AISM_ALL,
>>>> +        .addr = (uint64_t)&ais,
>>>> +    };
>>>> +
>>>> +    if (!ais_needed(flic)) {
>>>> +        return -ENOSYS;
>>>> +    }  
>>>
>>> I do not understand this... does that mean that
>>> - we should never get here or 
>>> - we should not try to change the fields or
>>> - I need coffee?  
>>
>> My understanding is that this should not happen with a normal setup, 
>> but it can happen if the user does something "wrong". For example
>> use qemu without libvirt and with -cpu host (which is not migration safe)
>> and do a migration from a host that has AIS to a host that has no AIS.
>> In that case the target system will reject the migration (late, but hopefully
>> not too late).
> 
> A comment would be helpful here.
> 

I was actually pushing for explaining the design decisions regarding these
corner cases (there is the inverse problem too) in the commit message
(during the internal review).

I'm not sure about this "wrong" though. Can one of you provide a
reference why is the scenario described "wrong". This question
decomposes into three: 
1) How do I, as a qemu developer, know what is the management
software supposed to do? (E.g. has to use a cpu model other than
host if it wants to migrate (probably).)
2) What can I assume about the stuff not properly covered in the
user manual when I reason "right" usage and "wrong" usage.
3) Is being 'fool-proof' a design goal, or are we satisfied with
providing mechanisms for using something safely and (like with
undefined behavior in C) don't really care about possible damage
if the user does not stick to these safe mechanisms (which are
documented as such)?

I've looked up the user manual regarding migration. It was not
very helpful regarding the matter of differentiating between
right and wrong usage.

Regards,
Halil