From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eBiyD-0006wA-0V for mharc-grub-devel@gnu.org; Mon, 06 Nov 2017 10:05:49 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47370) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eBiy6-0006vz-8X for grub-devel@gnu.org; Mon, 06 Nov 2017 10:05:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eBiy0-0006dq-HQ for grub-devel@gnu.org; Mon, 06 Nov 2017 10:05:42 -0500 Received: from mx2.suse.de ([195.135.220.15]:38485) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eBiy0-0006da-74 for grub-devel@gnu.org; Mon, 06 Nov 2017 10:05:36 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 57173ABB1; Mon, 6 Nov 2017 15:05:34 +0000 (UTC) Subject: Re: [Xen-devel] Xen PVH support in grub2 To: Boris Ostrovsky , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Cc: The development of GNU GRUB , Daniel Kiper , xen-devel References: <11dda1ae-5b70-41fe-a592-39750a74e5d7@suse.com> <20170929155104.45wv3c7civz6uif6@dhcp-3-128.uk.xensource.com> <20171103121750.jztbuimjjt34efk6@dhcp-3-128.uk.xensource.com> <7d4ea582-e936-35bf-fadb-58e11b1315ee@suse.com> <20171103140722.lrlokgese4mttojs@dhcp-3-128.uk.xensource.com> <25996301-31b8-a9d9-90d0-5221292801c4@suse.com> <92edc5f4-3ab0-1010-0a7d-b27b78f8eb6b@oracle.com> <82a3aa2a-dc63-01c0-737c-8c0529850d6d@suse.com> <3c916549-7f0c-b676-4bbe-08be68534afe@suse.com> <85903a23-a8eb-09cf-7858-f0b8a73bc2f9@oracle.com> <8b518988-dc93-1a82-5055-c3effaf3355a@suse.com> <04a4c318-552c-da75-a372-15fc64fd395d@suse.com> <073e6470-f844-d22f-22ab-4d47500fdfb5@oracle.com> From: Juergen Gross Message-ID: <6bb6959e-403c-9abd-e8e7-27090ee6aa02@suse.com> Date: Mon, 6 Nov 2017 16:05:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <073e6470-f844-d22f-22ab-4d47500fdfb5@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] [fuzzy] X-Received-From: 195.135.220.15 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 15:05:48 -0000 On 06/11/17 15:51, Boris Ostrovsky wrote: > On 11/06/2017 02:16 AM, Juergen Gross wrote: >> On 03/11/17 20:00, Boris Ostrovsky wrote: >>> On 11/03/2017 02:40 PM, Juergen Gross wrote: >>>> On 03/11/17 19:35, Boris Ostrovsky wrote: >>>>> On 11/03/2017 02:23 PM, Juergen Gross wrote: >>>>>> On 03/11/17 19:19, Boris Ostrovsky wrote: >>>>>>> On 11/03/2017 02:05 PM, Juergen Gross wrote: >>>>>>>> So again the question: how to tell whether we are PVH or HVM in >>>>>>>> init_hypervisor_platform()? ACPi tables are scanned way later... >>>>>>> Can we make grub/OVMF append a boot option? >>>>>>> >>>>>>> Or set setup_header.hardware_subarch to something? We already have >>>>>>> X86_SUBARCH_XEN but it is only used by PV. Or we might be able to use >>>>>>> hardware_subarch_data (will need to get a buy-in from x86 maintainers, I >>>>>>> think). >>>>>> But wouldn't this break the idea to reuse the native boot paths in >>>>>> grub/OVMF without further modifications? >>>>> WDYM? We will have to have some sort of a plugin in either one to build >>>>> the zeropage anyway. So we'd set hardware_subarch there, in addition to >>>>> other things like setting memory and such. >>>> But isn't the zeropage already being built? I admit that setting subarch >>>> isn't a big deal, but using another entry with a passed-through pvh >>>> start struct isn't either... >>> I don't follow, sorry. My understanding is that zeropage will be built >>> by PVH-enlightened grub so part of this process would be setting the >>> subarch bit. >> My reasoning was based on Roger's remark: >> >> "OTOH if Linux is capable of booting from the native entry point inside >> of a PVH container, we would only have to port OVMF and grub in order >> to work inside of a PVH container, leaving the rest of the logic >> untouched." > > Right, and in my mind porting OVMF/grub includes creating proper zeropage. Aah, okay. I reasoned on the assumption to just enable OVMF/grub to run in PVH environment without touching the parts setting up anything for the new kernel. > BTW, another option might be to "type_of_loader = (9 << 4) | 0", which > is what init_pvh_bootparams() does. In fact, whatever is done in the > firmware should probably match what that routine does. So it wouldn't be possible any longer to tell whether the kernel has been booted directly or via grub. I don't like this. The loader type is accessible via sysfs after all. Juergen