[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [qemu-s390x] [PATCH 1/1] s390x/sclp: fix maxram calculation
From: |
Christian Borntraeger |
Subject: |
Re: [qemu-s390x] [PATCH 1/1] s390x/sclp: fix maxram calculation |
Date: |
Mon, 30 Jul 2018 17:20:25 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 |
On 07/30/2018 05:17 PM, David Hildenbrand wrote:
> On 30.07.2018 17:00, Christian Borntraeger wrote:
>>
>>
>> On 07/30/2018 04:34 PM, David Hildenbrand wrote:
>>> On 30.07.2018 16:09, Christian Borntraeger wrote:
>>>> We clamp down ram_size to match the sclp increment size. We do
>>>> not do the same for maxram_size, which means for large guests
>>>> with some sizes (e.g. -m 50000) maxram_size differs from ram_size.
>>>> This can break other code (e.g. CMMA migration) which uses maxram_size
>>>> to calculate the number of pages and then throws some errors.
>>>
>>> So the only problem is that the buffer size between source and target
>>> differ?
>>
>> The problem is that the target tries to access a non-existing buffer when
>> committing all cmma value, so the kernel returns with EFAULT.
>>>
>
> Am I wrong or does CMMA migration code really not care about which parts
> of maxram are actually used (== which memory regions are actually defined)?
>
> If so, this looks broken to me and the right fix is to use ramsize for
> now, because it simply does not support maxram.
>
> (I assume using some -m X,maxmem=X+Y would make it fail in the same way)
>
> (this patch still makes sense and should be done)
I am looking for the minimal fix for 2.13 and ideally even for 2.12.1.
Can we agree on this fix and do the remaining thing later?
Re: [qemu-s390x] [PATCH 1/1] s390x/sclp: fix maxram calculation, Christian Borntraeger, 2018/07/30
Re: [qemu-s390x] [PATCH 1/1] s390x/sclp: fix maxram calculation, David Hildenbrand, 2018/07/30
Re: [qemu-s390x] [PATCH 1/1] s390x/sclp: fix maxram calculation, Cornelia Huck, 2018/07/30