From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752453AbdLGXGZ (ORCPT ); Thu, 7 Dec 2017 18:06:25 -0500 Received: from aserp2120.oracle.com ([141.146.126.78]:55668 "EHLO aserp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750973AbdLGXGX (ORCPT ); Thu, 7 Dec 2017 18:06:23 -0500 Subject: Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point To: Paolo Bonzini , 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: Maran Wilson Organization: Oracle Corporation Message-ID: <0b35e55b-47ec-c11a-bd56-75b37e868d31@oracle.com> Date: Thu, 7 Dec 2017 15:03:55 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8738 signatures=668644 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712070337 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Just FYI: I sent out a v2 of this patch but in doing so I moved a few people from the "to" line to the "cc" line. For anyone who previously did not comment but still wanted to follow the discussion, here's the link to the v2 email: https://lkml.org/lkml/2017/12/7/1624 Thanks, -Maran On 12/1/2017 12:08 AM, Paolo Bonzini wrote: > 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