From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751465AbdK3SXq (ORCPT ); Thu, 30 Nov 2017 13:23:46 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:28042 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750761AbdK3SXo (ORCPT ); Thu, 30 Nov 2017 13:23:44 -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: Date: Thu, 30 Nov 2017 10:23:17 -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: <25d6db63-a57d-b15c-2d43-e96c506b4824@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/29/2017 6:44 AM, Paolo Bonzini wrote: > 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 > inhttps://github.com/bonzini/qboot/blob/master/main.c) instead of the > second module. Hi Paolo, I want to make sure I understand exactly what you are suggesting... 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? 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. Thanks, -Maran