From owner-freebsd-amd64@freebsd.org Sun Jul 12 19:14:17 2020 Return-Path: Delivered-To: freebsd-amd64@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 24F0236B870 for ; Sun, 12 Jul 2020 19:14:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4c0820MPz3dy9 for ; Sun, 12 Jul 2020 19:14:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 06CJE9BU026899 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 12 Jul 2020 22:14:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 06CJE9BU026899 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 06CJE8ra026898; Sun, 12 Jul 2020 22:14:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 12 Jul 2020 22:14:08 +0300 From: Konstantin Belousov To: Lytochkin Boris Cc: freebsd-amd64@freebsd.org Subject: Re: More than 1G of loader-visible RAM? Message-ID: <20200712191408.GB44314@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4B4c0820MPz3dy9 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [2.91 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_SPAM_SHORT(0.25)[0.247]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; NEURAL_SPAM_MEDIUM(0.72)[0.715]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.95)[0.946]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2020 19:14:17 -0000 On Sun, Jul 12, 2020 at 12:32:08AM +0300, Lytochkin Boris wrote: > Hi. > > I am trying to make a patch that gives loader ability to bring whole > partitions as preload md(4) items. While this could sound a bit crazy, it > allows making an easy to get "diskless" routers: root partition is 2Gb > stored on HDD and I have 4Gb of RAM loader can get root partition into > memory and kernel will use it as a root partition. Once OS is up and > running, HDD can be set to sleep mode (via /etc/rc.local or similar) > > Currently I do the same thing via init_script that detects boot partition, > run mdconfig and dd. Delegating this job to loader will make this setup > much more straightforward. > > Currently my patch for loader can copy partitions up to ~1G and it seems > this is a limitation in stand/i386/libi386/elf64_freebsd.c: > ==== > /* > * This is kinda brutal, but every single 1GB VM memory segment points > to > * the same first 1GB of physical memory. But it is more than adequate. > */ > for (i = 0; i < 512; i++) { > ... > ==== > Comment comes from 2003 which was quite adequate back then. I am not that > fluent in real memory programming thus I write this email seeking a hint if > this 1Gb RAM limitation can be altered allowing more memory to be used by > loader that will be functional. Current setup requires 3 page table pages that are statically allocated in the loader data segment. Mapping each additional 1G would require one more page. This is doable but is not too friendly to limited space we have for loaders text + data, I think they are still have to live in low 640K for non-EFI boot. IMO what is wrong there is a protocol that requires mdroot to be fully mapped, I think it is only due to the way loader is coded right now. Kernel does not need anything from mdroot until pmap is fully initialized, so it really does not care much about this mapping.