Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753339AbdLHTaG (ORCPT ); Fri, 8 Dec 2017 14:30:06 -0500 Received: from aserp2130.oracle.com ([141.146.126.79]:39592 "EHLO aserp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753198AbdLHTaE (ORCPT ); Fri, 8 Dec 2017 14:30:04 -0500 Subject: Re: [RFC PATCH v2 0/2] KVM: x86: Allow Qemu/KVM to use PVH entry point To: Maran Wilson , pbonzini@redhat.com, jgross@suse.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 References: <1512686715-11488-1-git-send-email-maran.wilson@oracle.com> Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, rkrcmar@redhat.com, JBeulich@suse.com From: Boris Ostrovsky Message-ID: Date: Fri, 8 Dec 2017 14:21:45 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1512686715-11488-1-git-send-email-maran.wilson@oracle.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8739 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-1712080264 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 983 Lines: 26 On 12/07/2017 05:45 PM, Maran Wilson wrote: > > 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? I wonder whether the time has come for arch/x86/virt/ xen/ kvm/ hyperv/ kernel/paravirt* kernel/cpu/hypervisor.c -boris