From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1YroPS-0003yw-Hx for mharc-grub-devel@gnu.org; Mon, 11 May 2015 10:10:18 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52943) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YroPP-0003sN-Au for grub-devel@gnu.org; Mon, 11 May 2015 10:10:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YroPJ-0001cL-7M for grub-devel@gnu.org; Mon, 11 May 2015 10:10:15 -0400 Received: from mo6-p00-ob.smtp.rzone.de ([2a01:238:20a:202:5300::4]:13270) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YroPI-0001XS-Tp for grub-devel@gnu.org; Mon, 11 May 2015 10:10:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1431353405; l=1966; s=domk; d=aepfle.de; h=In-Reply-To:Content-Transfer-Encoding:Content-Disposition: Content-Type:MIME-Version:References:Subject:To:From:Date; bh=86++exx85pxiSrT9y+6zfTnLRLDzJ3zFJ7mraYm79SE=; b=R09ljZjWbP1CAN2c5hTeVDh/Ua94CzlNr/yMSFIUdlShvnDfKu67avGGNk+8OQF2UWG L5IS1jgL5wCylfOYyMoa2YzmU+orctAEWgBHTpj5GqXR4kGaaL1Jm7pUYQDeeOu6K4DB7 tT3NpfANUxP+DyTaYJpYhnCHCBSRjkqK22k= X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnBYfssVY1SE5ClEYfb5sQvxDNUdfk3GFAM3xrxaZN0YQ== X-RZG-CLASS-ID: mo00 Received: from probook.fritz.box ([2001:a60:10a3:eb01:1ec1:deff:feb9:bb48]) by smtp.strato.de (RZmta 37.5 AUTH) with ESMTPSA id R06aecr4BEA50Rf (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve sect571r1 with 571 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Mon, 11 May 2015 16:10:05 +0200 (CEST) Received: by probook.fritz.box (Postfix, from userid 1000) id 3C4B6502A7; Mon, 11 May 2015 16:10:05 +0200 (CEST) Date: Mon, 11 May 2015 16:10:05 +0200 From: Olaf Hering To: The development of GNU GRUB Subject: Re: passing options to grub in xen,openfirmware and efi Message-ID: <20150511141005.GA11233@aepfle.de> References: <20150429154801.GA7715@aepfle.de> <20150429162800.GA32494@aepfle.de> <20150429164921.GA9393@aepfle.de> <554B7A74.7010404@gmail.com> <20150507145426.GA26929@aepfle.de> <554B7DBA.8060501@gmail.com> <554B830A.8040400@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <554B830A.8040400@gmail.com> User-Agent: Mutt/1.5.22.rev6346 (2013-10-29) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a01:238:20a:202:5300::4 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 14:10:16 -0000 On Thu, May 07, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > most other firmwares like EFI or BIOS look for boot image at hardcoded > place e.g. MBR or ESP at predefined locations or uses NVRAM. The trouble > with passing this info from dom0 is that it's difficult to discover for > grub-install where to put image, in some cases this would even make > install impossible without modifying dom0. I feel like location which > changes all the time would create more confusion that hardcoded location > (E.g. I ran grub-install but my system still uses old GRUB) Thats exactly the point: other firmware have a notion of a boot-device. A PV guest currently has not, simply because grub has no code which looks at the info passed to it. How that info is interpreted is up to that very grub itself. Regerading discovery: In a PV domU storing the boot binary within that domU is equal to all other systems: it goes where /boot/xen/ is. There is nothing to detect from within domU. And in case some scripts have to refer to a disk, that info is in sysfs: /dev/xvda translates to xen/xvda etc [1]. Not sure if grub-install within domU does include such info into the binary. If it does, fine. If not, we are back to square one: The first grub (kernel= in domU.cfg) may get a variable where to look for the second (guest admin controlled) grub. And this variable should be passed on to that second grub to make it aware where it was loaded from. If there is no variable the first grub is free to search for the second grub. Even in this case it makes sense to tell that second grub where it came from. Olaf [1]: I see grub-core/disk/xen/xendisk.c:fill uses either xen/ or xenid/ as prefix. No idea how the second case can happen in practice. I dont know the backend/frontend protocol well enough. This case can likely be detected as well within domU. After all the kernel has to assign some name to such device. Olaf