[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFCv2 3/6] s390x/diag: implement diag260
From: |
David Hildenbrand |
Subject: |
Re: [PATCH RFCv2 3/6] s390x/diag: implement diag260 |
Date: |
Wed, 15 Jul 2020 13:13:05 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 |
On 15.07.20 12:53, Heiko Carstens wrote:
> On Wed, Jul 15, 2020 at 11:19:03AM +0200, David Hildenbrand wrote:
>> On 14.07.20 12:17, Claudio Imbrenda wrote:
>>> shouldn't it return all the hotplugged areas once hotplugging is
>>> enabled?
>>
>> No, that would be dangerous and wrong. Memory ranges part of memory
>> devices never must be indicated as part of hw/firmware interfaces to
>> indicate valid boot memory. Memory provided via memory devices
>> (virtio-mem, virtio-pmem, ...) has different semantics than ordinary
>> hotplugged memory, and unmodified OSs (esp., older Linux versions)
>> should not silently try to make use of any such memory. It's not just
>> some hotplugged memory a guest OS should detect+use during boot as
>> system ram. Thanks!
>
> How is kdump supposed to work, if there is no mechanism to figure out
> which memory ranges have been added dynamically to the system?
Like other archs (esp x86-64), we would want to revive letting user
space (kexec-tools) prepare the dump header, specifying the memory
ranges. Would be necessary under KVM only, if virtio-mem is detected.
(Note: I am not sure if we would currently dump standby memory that has
been onlined from a kdump kernel.)
--
Thanks,
David / dhildenb
[PATCH RFCv2 5/6] s390x: implement virtio-mem-ccw, David Hildenbrand, 2020/07/10
[PATCH RFCv2 6/6] s390x: initial support for virtio-mem, David Hildenbrand, 2020/07/10