From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751173AbdJBKSU (ORCPT ); Mon, 2 Oct 2017 06:18:20 -0400 Received: from mail-qk0-f194.google.com ([209.85.220.194]:33460 "EHLO mail-qk0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750949AbdJBKSS (ORCPT ); Mon, 2 Oct 2017 06:18:18 -0400 X-Google-Smtp-Source: AOwi7QBZ74iT7zd5eCp4Ku+4zqwyx9n4P0qwhQaNjG848oVdJy+CNkqRGCXhuFPRAnfR9tOKBoS4uw6ucgVsoiz0pX8= MIME-Version: 1.0 In-Reply-To: <4102561f-b403-735e-a18a-7c55db57df74@redhat.com> References: <4102561f-b403-735e-a18a-7c55db57df74@redhat.com> From: George Dunlap Date: Mon, 2 Oct 2017 11:18:16 +0100 X-Google-Sender-Auth: tuCcMoO8_d7wecjJ-61mKhOIqLY Message-ID: Subject: Re: [Xen-devel] KVM PV (was: Re: [PATCH v2 2/2] x86/lguest: remove lguest support) To: Paolo Bonzini Cc: Lai Jiangshan , LKML , kvm@vger.kernel.org, Juergen Gross , rusty@rustcorp.com.au, lguest@lists.ozlabs.org, "the arch/x86 maintainers" , Ingo Molnar , "H. Peter Anvin" , xen-devel , Boris Ostrovsky , Thomas Gleixner Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 29, 2017 at 5:39 PM, Paolo Bonzini wrote: > On 29/09/2017 17:47, Lai Jiangshan wrote: >> Hello, all >> >> An interesting (at least to me) thinking came up to me when I found >> that the lguest was removed. But I don't have enough knowledge >> to find out the answer nor energy to implement it in some time. >> >> Is it possible to implement kvm-pv which allows kvm to run on >> the boxes without hardware virtualization support, so that >> qemu/kvm can be used on clouds such as aws, azure? > > No, please don't. :) Even Xen is moving from PV to PVH (paravirtualized > hardware with event channels, grant tables and the like, but still using > hardware extensions for MMU). That said, the main pain point for Xen's PV so far has been the fact that we expose the real pagetables directly to the guest, in order to avoid having to do use shadow pagetables. If you're willing to take the performance hit and use an existing shadow pagetable implementation from the start, it might not be so bad from a development perspective. Still, I'm betting it will be a lot more work than you expect. :-) -George