[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH RFC 2/5] s390x: implement diag260

From: David Hildenbrand
Subject: Re: [PATCH RFC 2/5] s390x: implement diag260
Date: Fri, 10 Jul 2020 14:12:33 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0

On 10.07.20 11:17, David Hildenbrand wrote:
> On 09.07.20 20:15, David Hildenbrand wrote:
>> On 09.07.20 12:52, Christian Borntraeger wrote:
>>> On 08.07.20 20:51, David Hildenbrand wrote:
>>>> Let's implement the "storage configuration" part of diag260. This diag
>>>> is found under z/VM, to indicate usable chunks of memory tot he guest OS.
>>>> As I don't have access to documentation, I have no clue what the actual
>>>> error cases are, and which other stuff we could eventually query using this
>>>> interface. Somebody with access to documentation should fix this. This
>>>> implementation seems to work with Linux guests just fine.
>>>> The Linux kernel supports diag260 to query the available memory since
>>>> v4.20. Older kernels / kvm-unit-tests will later fail to run in such a VM
>>>> (with maxmem being defined and bigger than the memory size, e.g., "-m
>>>>  2G,maxmem=4G"), just as if support for SCLP storage information is not
>>>> implemented. They will fail to detect the actual initial memory size.
>>>> This interface allows us to expose the maximum ramsize via sclp
>>>> and the initial ramsize via diag260 - without having to mess with the
>>>> memory increment size and having to align the initial memory size to it.
>>>> This is a preparation for memory device support. We'll unlock the
>>>> implementation with a new QEMU machine that supports memory devices.
>>>> Signed-off-by: David Hildenbrand <david@redhat.com>
>>> I have not looked into this, so this is purely a question. 
>>> Is there a way to hotplug virtio-mem memory beyond the initial size of 
>>> the memory as specified by the  initial sclp)? then we could avoid doing
>>> this platform specfic diag260?
>> We need a way to tell the guest about the maximum possible PFN, so it
>> can prepare for that. E.g. on x86-64 this is usually done via ACPI SRAT
>> tables. On s390x, the only way I see is using a combination of diag260,
>> without introducing any other new mechanisms.
>> Currently Linux selects 3. vs 4 level page tables based on that size (I
>> think that's what you were referring to with the 4TB limit). I can see
>> that kasan also does some magic based on the value ("populate kasan
>> shadow for untracked memory"), but did not look into the details. I
>> *think* kasan will never be able to track that memory, but am not
>> completely sure.
>> I'd like to avoid something as you propose (that's why I searched and
>> discovered diag260 after all :) ), especially to not silently break in
>> the future, when other assumptions based on that value are introduced.
>> E.g., on my z/VM LinuxOne Community Cloud machine, diag260 gets used as
>> default, so it does not seem to be a corner case mechanism nowadays.
> Note: Reading about diag260 subcode 0xc, we could modify Linux to query
> the maximum possible pfn via diag260 0xc. Then, we maybe could avoid
> indicating maxram size via SCLP, and keep diag260-unaware OSs keep
> working as before. Thoughts?

Implemented it, seems to work fine.


David / dhildenb

reply via email to

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