qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]