[SLOF] [PATCH v2] boot: do not use catpad to concatenate strings

[Thomas Huth]

On 07.12.2017 11:36, David Gibson wrote:
> On Thu, Dec 07, 2017 at 03:54:45PM +0530, Nikunj A Dadhania wrote:
>> Thomas Huth <thuth at redhat.com> writes:
>>
>>> On 01.12.2017 11:29, Nikunj A Dadhania wrote:
>>>> The catpad size is 1K size, which can be hit easily hit with around 20 devices
>>>> with bootindex.
>>>>
>>>> Open code EVALUATE such that concatenation is not required. Replace usage of
>>>> $cat with a 16K buffer allocated here.
>>>>
>>>> Reported here: https://github.com/qemu/SLOF/issues/3
>>>>
>>>> Signed-off-by: Nikunj A Dadhania <nikunj at linux.vnet.ibm.com>
>>>>
>>>> ---
>>>>
>>>> qemu-system-ppc64 -nographic -nodefaults -serial stdio -monitor pty -m 2G \
>>>> -device virtio-scsi-pci    \
>>>> `for ((i=2;i<=50;i++)) ; \
>>>> do echo -n "  -drive file=/tmp/storage$i.qcow2,if=none,id=drive$i,format=qcow2 \
>>>> -device
>>>> scsi-hd,drive=drive$i,id=disk$i,channel=0,scsi-id=0,lun=$i,bootindex=$i"; \
>>>> done;` \
>>>> -drive file=guest.disk,if=none,id=drv1,format=qcow2,cache=none \
>>>> -device scsi-hd,drive=drv1,bootindex=1 -boot menu=on,splash-time=3000,strict=on
>>>> ---
>>>>  slof/fs/boot.fs | 30 +++++++++++++++++++++++++-----
>>>>  1 file changed, 25 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/slof/fs/boot.fs b/slof/fs/boot.fs
>>>> index 1fd7439..8a30195 100644
>>>> --- a/slof/fs/boot.fs
>>>> +++ b/slof/fs/boot.fs
>>>> @@ -15,6 +15,9 @@
>>>>  VARIABLE state-valid false state-valid !
>>>>  CREATE go-args 2 cells allot go-args 2 cells erase
>>>>  
>>>> +4000 CONSTANT BOOT_DEV_SIZE
>>>> +CREATE bootdev-buf BOOT_DEV_SIZE allot
>>>
>>> I somehow dislike the idea that we statically reserve such big arrays
>>> ... would it be feasible to do this with alloc-mem on the fly instead?
>>
>> Let me try that out
> 
> Don't try too hard.  I mean, sure a large static array is kinda ugly, but
> when it comes down it the whole guest's memory is there with nothing
> else to use it for until SLOF's done.

SLOF is located at the end of the memory, so the available amount of its
usable memory with "allot" is also limited. Of course we could reserve
more memory for SLOF again one day, but discovering that we run into
that situation again will also be a pain. So let's try at least to not
waste to much memory right now, ok?

 Thomas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/slof/attachments/20171207/f69d53a4/attachment-0001.sig>