From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932643AbdK2OoY (ORCPT ); Wed, 29 Nov 2017 09:44:24 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59878 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932435AbdK2OoW (ORCPT ); Wed, 29 Nov 2017 09:44:22 -0500 Subject: Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point To: Boris Ostrovsky , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Juergen Gross Cc: Maran Wilson , tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, rkrcmar@redhat.com, JBeulich@suse.com, andrew.cooper3@citrix.com, kvm@vger.kernel.org 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> From: Paolo Bonzini Message-ID: <25d6db63-a57d-b15c-2d43-e96c506b4824@redhat.com> Date: Wed, 29 Nov 2017 15:44:14 +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: <96f9b4a5-7cb6-19c3-227d-8c48916d5969@oracle.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 29 Nov 2017 14:44:22 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. I actually like this patch, except that I'd get the e820 memory map from fw_cfg (see the first part of https://github.com/bonzini/qboot/blob/master/fw_cfg.c, and extract_e820 in https://github.com/bonzini/qboot/blob/master/main.c) instead of the second module. Thanks, Paolo > >> But then it won't be using the PVH entry point, and would just use the >> native one? >> >> My understanding was that the PVH shim inside of Linux will prepare a >> zero-page when booted using the PVH entry point, and then jump into >> the native boot path. > Right, but that's not what Juergen's second option is. IIUIC with that > option Linux starts with zeropage already prepared. No shim in the kernel.