From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eBkSl-0007T5-Su for mharc-grub-devel@gnu.org; Mon, 06 Nov 2017 11:41:27 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56203) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eBkSj-0007Sx-ID for grub-devel@gnu.org; Mon, 06 Nov 2017 11:41:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eBkSg-0004CN-Te for grub-devel@gnu.org; Mon, 06 Nov 2017 11:41:25 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:46776) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eBkSg-0004Bu-Jf for grub-devel@gnu.org; Mon, 06 Nov 2017 11:41:22 -0500 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA6GfJv4006226 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 6 Nov 2017 16:41:19 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA6GfIrC012083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 6 Nov 2017 16:41:18 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA6GfHxr003075; Mon, 6 Nov 2017 16:41:18 GMT Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com (/10.152.32.65) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 06 Nov 2017 08:41:17 -0800 Subject: Re: [Xen-devel] Xen PVH support in grub2 To: Juergen Gross , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <11dda1ae-5b70-41fe-a592-39750a74e5d7@suse.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> <6bb6959e-403c-9abd-e8e7-27090ee6aa02@suse.com> Cc: The development of GNU GRUB , Daniel Kiper , xen-devel , Konrad Rzeszutek Wilk From: Boris Ostrovsky Message-ID: <09a7d748-a5ac-afb0-1158-a5e49b30edac@oracle.com> Date: Mon, 6 Nov 2017 11:42:49 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <6bb6959e-403c-9abd-e8e7-27090ee6aa02@suse.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 141.146.126.69 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 16:41:26 -0000 On 11/06/2017 10:05 AM, Juergen Gross wrote: > 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. Someone needs to do what xen_prepare_pvh() does. And, for 64-bit, we also may need to build early pagetables since startup_64() (unlike startup_32()) expects paging to be on. (I don't know whether this is already part of standard FW codepath) > >> 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. I didn't know that. What is the path? -boris