[SLOF] [PATCH 2/2] Increase temporary buffer size of ibm, client-architecture-support call

[Thomas Huth]

On 23.12.2015 06:26, Nikunj A Dadhania wrote:
> Thomas Huth <thuth at redhat.com> writes:
> 
>> The buffer size that we currently use for the client-architecture-
>> support call currently only works if there is not more than 1 TiB
>> of hot-pluggable RAM for the guest. This will likely not be enough
>> in the near future, so increase the buffer size from 128 kiB to 2 MiB
>> instead. That should be enough to accomodate for 16 TiB of hot-pluggable
>> memory.
>> While we're at it, also rename the "size" variable to something more
>> specific (since it is put into the namespace of the root node), and
>> add a proper error message in case the alloc-mem fails.
>>
>> Signed-off-by: Thomas Huth <thuth at redhat.com>
>> ---
>>  board-qemu/slof/archsupport.fs | 13 +++++++------
>>  1 file changed, 7 insertions(+), 6 deletions(-)
>>
>> diff --git a/board-qemu/slof/archsupport.fs b/board-qemu/slof/archsupport.fs
>> index f564ab4..a8ace3c 100644
>> --- a/board-qemu/slof/archsupport.fs
>> +++ b/board-qemu/slof/archsupport.fs
>> @@ -10,15 +10,16 @@
>>  \ *     IBM Corporation - initial implementation
>>  \ ****************************************************************************/
>>
>> -\ 128KB FDT buffer size is enough to accommodate 255 CPU cores and 1TB of
>> -\ maxmem specification.
>> -20000 VALUE size
>> +\ 2 MiB FDT buffer size is enough to accommodate 255 CPU cores
>> +\ and 16 TiB of maxmem specification.
>> +200000 CONSTANT cas-buffer-size
>>  : ibm,client-architecture-support         ( vec -- err? )
>>      \ Store require parameters in nvram
>>      \ to come back to right boot device
>>      \ Allocate memory for H_CALL
>> -    size alloc-mem                        ( vec memaddr )
>> -    swap over size                        ( memaddr vec memaddr size )
>> +    cas-buffer-size alloc-mem             ( vec memaddr )
>> +    dup 0= IF ." out of memory during ibm,client-architecture-support" cr THEN
> 
> And return error back to the client in place of going forward.

Right ... anyway, in the long run, we need to do something different
here, since alloc-mem does not scale. Any ideas how this could be fixed
in a better way? I really dislike the idea of using a hypercall with a
fixed buffer size... I haven't looked at this
ibm,client-architecture-support in details yet, but maybe qemu could
also provide the properties by default right from the start, and then
SLOF would simply remove them again during the
ibm,client-architecture-support call when they are not needed? Would
that work, too?
Or maybe it would be sufficient to pass a template for one node, and
SLOF would then iterate over all other device tree nodes?
Or if everything else fails, we should maybe use "claim" to allocate the
memory instead - assuming that the client program has not claimed all
memory yet, and we can get bigger buffers this way?

 Thomas