Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752580AbdLGWr0 (ORCPT ); Thu, 7 Dec 2017 17:47:26 -0500 Received: from aserp2130.oracle.com ([141.146.126.79]:44910 "EHLO aserp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751625AbdLGWrY (ORCPT ); Thu, 7 Dec 2017 17:47:24 -0500 From: Maran Wilson To: pbonzini@redhat.com, jgross@suse.com, boris.ostrovsky@oracle.com, roger.pau@citrix.com, andrew.cooper3@citrix.com, hch@infradead.org, x86@kernel.org, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, rkrcmar@redhat.com, JBeulich@suse.com Subject: [RFC PATCH v2 0/2] KVM: x86: Allow Qemu/KVM to use PVH entry point Date: Thu, 7 Dec 2017 14:45:13 -0800 Message-Id: <1512686715-11488-1-git-send-email-maran.wilson@oracle.com> X-Mailer: git-send-email 1.8.3.1 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-1712070332 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1403 Lines: 31 Changes from v1: * Adopted Paolo's suggestion for defining a v2 PVH ABI that includes the e820 map instead of using the second module entry to pass the table. * Cleaned things up a bit to reduce the number of xen vs non-xen special cases. Juergen also had a suggestion to split the different hypervisor types early and use a common set of service functions instead of special casing xen_guest everywhere. There are certainly less special cases in this version of the patch, but if we still think it's important to split things up between common, Xen, and KVM components, then I would appreciate a suggestion on how best that can be done. Are we talking about just re-factoring functions in the existing file? Or do we need to go all the way and pull all the PVH entry code out of xen directories and find a home for it somewhere else so that we can use kernels built without CONFIG_XEN to start KVM guests via the PVH entry point. If the latter, any suggestions for which common files or directories I can move this stuff to? Maran Wilson (2): xen/pvh: Add memory map pointer to hvm_start_info struct KVM: x86: Allow Qemu/KVM to use PVH entry point arch/x86/xen/enlighten_pvh.c | 48 +++++++++++++++++++++++++++++++++--------------- include/xen/interface/hvm/start_info.h | 34 +++++++++++++++++++++++++++++++--- 2 files changed, 64 insertions(+), 18 deletions(-)