On Fri, Jul 10, 2020 at 05:24:07PM +0200, David Hildenbrand wrote: > On 10.07.20 17:18, Heiko Carstens wrote: > > On Fri, Jul 10, 2020 at 02:12:33PM +0200, David Hildenbrand wrote: > >>> 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. > > > > The returned value would not include standby/reserved memory within > > z/VM. So this seems not to work. > > Which value exactly are you referencing? diag 0xc returns two values. > One of them seems to do exactly what we need. > > See > https://github.com/davidhildenbrand/linux/commit/a235f9fb20df7c04ae89bc0d134332d1a01842c7 > > for my current Linux approach. > > > Also: why do you want to change this > > Which change exactly do you mean? > > If we limit the value returned via SCLP to initial memory, we cannot > break any guest (e.g., Linux pre 4.2, kvm-unit-tests). diag260 is then > purely optional.
Ok, now I see the context. Christian added my just to cc on this specific patch. So if I understand you correctly, then you want to use diag 260 in order to figure out how much memory is _potentially_ available for a guest? This does not fit to the current semantics, since diag 260 returns the address of the highest *currently* accessible address. That is: it does explicitly *not* include standby memory or anything else that might potentially be there. So you would need a different interface to tell the guest about your new hotplug memory interface. If sclp does not work, then maybe a new diagnose(?).
