From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755428AbdK2Owu (ORCPT ); Wed, 29 Nov 2017 09:52:50 -0500 Received: from smtp.ctxuk.citrix.com ([185.25.65.24]:25349 "EHLO SMTP.EU.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751546AbdK2Ows (ORCPT ); Wed, 29 Nov 2017 09:52:48 -0500 X-IronPort-AV: E=Sophos;i="5.44,473,1505779200"; d="scan'208";a="63911172" Subject: Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point To: Juergen Gross , Paolo Bonzini , Boris Ostrovsky , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= CC: Maran Wilson , , , , , , , , , References: <1511897682-32060-1-git-send-email-maran.wilson@oracle.com> <176188ca-51f9-ef12-6e93-46ab2d8b8cfc@suse.com> <20171129085044.kc3yqqdcw3zmp2k2@MacBook-Pro-de-Roger.local> <4d213199-ea65-4410-5b7a-63038215e380@oracle.com> <0162f2cd-2d9e-1c89-bb8e-7ac0089f0b3a@suse.com> <20171129141810.q3s3xflsflpjovdd@MacBook-Pro-de-Roger.local> <96f9b4a5-7cb6-19c3-227d-8c48916d5969@oracle.com> <25d6db63-a57d-b15c-2d43-e96c506b4824@redhat.com> From: Andrew Cooper Message-ID: <7eeb433d-e72a-68e8-bef6-eb695d55fe79@citrix.com> Date: Wed, 29 Nov 2017 14:52:43 +0000 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: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29/11/17 14:47, Juergen Gross wrote: > On 29/11/17 15:44, Paolo Bonzini wrote: >> On 29/11/2017 15:25, Boris Ostrovsky wrote: >>>>>> zeropage is x86/Linux-specific so we'd need some sort of firmware (like >>>>>> grub) between a hypervisor and Linux to convert hvm_start_info to >>>>>> bootparams. >>>>> qemu? >>> I think KVM folks didn't want to do this. I can't find the thread but I >>> believe it was somewhere during Clear Containers discussion. Paolo? >> QEMU is the right place to parse the ELF file and save it in memory. >> You would have to teach QEMU to find the Xen note in ELF-format kernels >> (just like it looks for the multiboot header), and use a different >> option ROM ("pvhboot.c" for example). >> >> However I don't like to bypass the BIOS; for -kernel, KVM starts the >> guest with an option ROM (linuxboot-dma.c or multiboot.S in QEMU >> sources) that takes care of boot. >> >> In either case, you would have a new option ROM. It could either be >> very simple and similar to multiboot.S, or it could be larger and do the >> same task as xen-pvh.S and enlighten_pvh.c (then get the address of >> startup_32 or startup_64 from FW_CFG_KERNEL_ENTRY and jump there). The >> ugly part is that the option ROM would have to know more details about >> what it is going to boot, including for example whether it's 32-bit or >> 64-bit, so I don't really think it is a good idea. > As grub2 doesn't have to know, qemu shouldn't have to know either. An underlying requirement for this boot protocol was to remove the requirement for a priori knowledge of the eventual mode of the guest, which plagues Xen PV guests.  (One way or another, we need to parse the kernel which will end up running to work out how to build the domain for it.) 32bit flat mode is easy to set up, sufficiently large for any reasonable bootstrapping, and provides no restrictions to what the eventual guest wants to do. ~Andrew