From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751156AbdLAIJL (ORCPT ); Fri, 1 Dec 2017 03:09:11 -0500 Received: from mail-wr0-f196.google.com ([209.85.128.196]:43912 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750891AbdLAIJK (ORCPT ); Fri, 1 Dec 2017 03:09:10 -0500 X-Google-Smtp-Source: AGs4zMYnz8M4oCAeaRExRoRz81q6N1lWGS9jqVFpU1GSDYaKptGDyQSYTiry8N1OWlGLwj6uGP4pYQ== Subject: Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point To: Maran Wilson , Boris Ostrovsky , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Juergen Gross Cc: 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> <25d6db63-a57d-b15c-2d43-e96c506b4824@redhat.com> From: Paolo Bonzini Message-ID: Date: Fri, 1 Dec 2017 09:08:59 +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: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30/11/2017 19:23, Maran Wilson wrote: > Are you saying the Linux PVH entry code (such as init_pvh_bootparams()) > should use the fw_cfg interface to read the e820 memory map data and put > it into the zeropage? Basically, keeping the patch very much like it > already is, just extracting the e820 data via the fw_cfg interface > instead of from the second module of start_info struct? Yes. > If that is the case, I guess I'm a bit hesitant to throw the QEMU > specific fw_cfg interface into the mix on the Linux PVH side when the > existing PVH ABI already seems to contain an interface for passing > modules/blobs to the guest. But if you feel there is a compelling reason > to use the fw_cfg interface here, I'm happy to explore that approach > further. I think the same holds true for Xen, but it is still using a hypercall to get the memory map. In the end, using fw_cfg seems closest to what the Xen code does. There are other possibilities: 1) defining a v2 PVH ABI that includes the e820 map would also be a possibility. 2) modify enlighten_pvh.c to get the start info in multiboot format, something like: diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c index 98ab17673454..656e41449db0 100644 --- a/arch/x86/xen/enlighten_pvh.c +++ b/arch/x86/xen/enlighten_pvh.c @@ -88,19 +88,22 @@ void __init xen_prepare_pvh(void) u32 msr; u64 pfn; - if (pvh_start_info.magic != XEN_HVM_START_MAGIC_VALUE) { + if (pvh_start_info.magic == XEN_HVM_START_MAGIC_VALUE) { + xen_pvh = 1; + + init_pvh_bootparams_xen(); + + msr = cpuid_ebx(xen_cpuid_base() + 2); + pfn = __pa(hypercall_page); + wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32)); + + x86_init.oem.arch_setup = xen_pvh_arch_setup; + } else if (pvh_start_info.magic == MULTIBOOT_INFO_MAGIC_VALUE) { + init_pvh_bootparams_multiboot(); + + } else { xen_raw_printk("Error: Unexpected magic value (0x%08x)\n", pvh_start_info.magic); BUG(); } - - xen_pvh = 1; - - msr = cpuid_ebx(xen_cpuid_base() + 2); - pfn = __pa(hypercall_page); - wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32)); - - init_pvh_bootparams(); - - x86_init.oem.arch_setup = xen_pvh_arch_setup; } Note that this would *not* be a multiboot-format kernel, as it would still have the Xen PVH ELF note. It would just reuse the format of the start info struct. However, I think it is simpler to just use the e820 memory map from fw_cfg. Paolo