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

[David Hildenbrand]

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?


-- 
Thanks,

David / dhildenb