From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eAgzw-0007jH-09 for mharc-grub-devel@gnu.org; Fri, 03 Nov 2017 14:47:20 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57212) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAgzt-0007hc-Bv for grub-devel@gnu.org; Fri, 03 Nov 2017 14:47:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eAgzq-0005T7-AT for grub-devel@gnu.org; Fri, 03 Nov 2017 14:47:17 -0400 Received: from mx2.suse.de ([195.135.220.15]:47797) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eAgzq-0005RM-3B for grub-devel@gnu.org; Fri, 03 Nov 2017 14:47:14 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id C3600ABB1; Fri, 3 Nov 2017 18:47:12 +0000 (UTC) Subject: Re: [Xen-devel] Xen PVH support in grub2 To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Cc: Boris Ostrovsky , The development of GNU GRUB , Daniel Kiper , xen-devel References: <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> <20171103183738.ball4ynnnu6ijq65@dhcp-3-128.uk.xensource.com> From: Juergen Gross Message-ID: <227a6bc2-75e0-0615-56e5-ea47222c1a21@suse.com> Date: Fri, 3 Nov 2017 19:47:12 +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: <20171103183738.ball4ynnnu6ijq65@dhcp-3-128.uk.xensource.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable 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: Fri, 03 Nov 2017 18:47:18 -0000 On 03/11/17 19:37, Roger Pau Monn=C3=A9 wrote: > On Fri, Nov 03, 2017 at 07:23:50PM +0100, 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 us= e >>> 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? >> >> I'd rather have a way to ask the hypervisor whether we are in PVH mode >> (e.g. via CPUID or a hypercall to test for a devicemodel having itself >> registered). >=20 > Keep in mind that from Xen's PoV PVH is just a HVM guest. Xen > currently keeps a bitmap of the emulated devices that are available to > a guest, but that's so far an internal field. We could consider > exporting this on a cpuid leaf, but then we need to make it a fixed > ABI. >=20 > Maybe we can make a list of platform devices that are not available on > PVH and that Linux assumes to be present? The main problem in Linux is that we have to know whether we are a HVM or a PVH guest. Okay, we could scan for the Xen PCI-device to make the distinction, but this is again rather late in the boot process. Using implicit assumptions is normally a bad way to make such a decision. I'd rather be either told by the boot loader I'm running as PVH guest (and the boot loader does know it), or I want to ask the hypervisor (which right now doesn't know), or I need another clear distinction like the existence of the Xen PCI-device (which might be a problem in the future for a PVH dom0 in a nested Xen environment). Juergen