On 13.07.20 12:27, David Hildenbrand wrote: > > >> Am 13.07.2020 um 11:12 schrieb Heiko Carstens <h...@linux.ibm.com>: >> >> 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. > > I tried to Cc you an all patches but the mail bounced with unknown address > (maybe I messed up). > >> 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? > > Yes, exactly. > >> >> 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. > > The confusing part is that it talks about „adressible“ and not „accessible“. > Now that I understood the „DEFINE STORAGE ...“ example, it makes sense that > the values change with reserved/standby memory. > > I agree that reusing that interface might not be what we want. I just seemed > too easy to avoid creating something new :) > >> >> 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(?). >> > > Yes, I think a new Diagnose makes sense. I‘ll have a look next week to figure > out which codes/subcodes we could use. @Christian @Conny any ideas/pointers?>
Wouldnt sclp be the right thing to provide the max increment number? (and thus the max memory address) And then (when I got the discussion right) use diag 260 to get the _current_ value.
