Re: [Qemu-devel] [PATCH for-2.5 7/8] s390x: Migrate guest storage keys (initial memory only)

[Christian Borntraeger <borntraeger@de.ibm.com>]

Am 21.07.2015 um 12:37 schrieb David Hildenbrand:
>>
>> So if I've got this code right, you send here a "header" that announces
>> a packet with all pages ...
>>
>>> +    while (handled_count < total_count) {
>>> +        cur_count = MIN(total_count - handled_count, S390_SKEYS_BUFFER_SIZE);
>>> +
>>> +        ret = skeyclass->get_skeys(ss, cur_gfn, cur_count, buf);
>>> +        if (ret < 0) {
>>> +            error_report("S390_GET_KEYS error %d\n", ret);
>>> +            break;
>>
>> ... but when an error occurs here, you suddenly stop in the middle of
>> that "packet" with all pages ...
> 
> Indeed, although that should never fail, we never know.

I think -ENOMEM would be a possible return code.

> We don't want to overengineer the protocol but still abort migration at least
> on the loading side in that (theoretical) case.
[..]

>>> +end_stream:
>>> +    qemu_put_be64(f, S390_SKEYS_SAVE_FLAG_EOS);

what about  sending zeroes for failed keys
defining an error code

 #define S390_SKEYS_SAVE_FLAG_EOS 0x01
 #define S390_SKEYS_SAVE_FLAG_SKEYS 0x02
+#define S390_SKEYS_SAVE_FLAG_FAILED 0x03

and then do 
	if (ok) {
		 qemu_put_be64(f, S390_SKEYS_SAVE_FLAG_EOS);
	} else {
		 qemu_put_be64(f, S390_SKEYS_SAVE_FLAG_FAILED);
	}

and the let target system fail migration (which should let the guest run at the source system?)