From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eCeyY-0006nC-WA for mharc-grub-devel@gnu.org; Thu, 09 Nov 2017 00:02:03 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59046) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCeyW-0006mW-5m for grub-devel@gnu.org; Thu, 09 Nov 2017 00:02:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eCeyT-0005pa-3H for grub-devel@gnu.org; Thu, 09 Nov 2017 00:02:00 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:35869) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eCeyS-0005pN-Ql for grub-devel@gnu.org; Thu, 09 Nov 2017 00:01:57 -0500 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA951qRY030619 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 9 Nov 2017 05:01:52 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA951q6j015435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 9 Nov 2017 05:01:52 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA951pSC021784; Thu, 9 Nov 2017 05:01:51 GMT Received: from char.us.oracle.com (/10.137.176.158) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 08 Nov 2017 21:01:50 -0800 Received: by char.us.oracle.com (Postfix, from userid 1000) id CA9AE6A04D7; Thu, 9 Nov 2017 00:01:49 -0500 (EST) Date: Thu, 9 Nov 2017 00:01:49 -0500 From: Konrad Rzeszutek Wilk To: Boris Ostrovsky , maran.wilson@oracle.com Cc: Juergen Gross , Roger Pau =?iso-8859-1?Q?Monn=E9?= , The development of GNU GRUB , Daniel Kiper , xen-devel Subject: Re: [Xen-devel] Xen PVH support in grub2 Message-ID: <20171109050149.GC13715@char.us.oracle.com> References: <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> <09a7d748-a5ac-afb0-1158-a5e49b30edac@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Source-IP: userv0022.oracle.com [156.151.31.74] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 156.151.31.81 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: Thu, 09 Nov 2017 05:02:01 -0000 On Tue, Nov 07, 2017 at 11:10:29AM -0500, Boris Ostrovsky wrote: > On 11/07/2017 02:42 AM, Juergen Gross wrote: > > On 06/11/17 17:42, Boris Ostrovsky wrote: > >> 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. > > As the loader is filling in the memory map information > > That's the thing that I thought may need to be done by us (setting > commandline too) . But I haven't looked at Xen support in grub so maybe > it's already there. > > > the only thing > > remaining would be setting xen_pvh. And this could be delayed as my test > > have shown, so we only need to detect the PVH case from inside the > > kernel. One possibility would be the flags in the ACPI FADT table as > > Roger mentioned, another idea would be a flag in zeropage set by the > > loader. > > > >> 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) > > This would be done the same way as for a native kernel. > > This is done by Linux trampoline code. AFAIK grub loads kernel in realmode. Adding in Maran who is looking at re-using PVH for qemu launching the kernels. > > > -boris > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel