[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH for-2.5 7/8] s390x: Migrate guest storage keys (
From: |
Christian Borntraeger |
Subject: |
Re: [Qemu-devel] [PATCH for-2.5 7/8] s390x: Migrate guest storage keys (initial memory only) |
Date: |
Thu, 13 Aug 2015 17:44:16 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 |
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?)