From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 174AAC432C2 for ; Thu, 26 Sep 2019 09:41:54 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E211C222BE for ; Thu, 26 Sep 2019 09:41:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E211C222BE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:33056 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iDQHZ-00035R-55 for qemu-devel@archiver.kernel.org; Thu, 26 Sep 2019 05:41:53 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58550) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iDQGt-0002dh-Jj for qemu-devel@nongnu.org; Thu, 26 Sep 2019 05:41:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iDQGs-0007LP-L7 for qemu-devel@nongnu.org; Thu, 26 Sep 2019 05:41:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45298) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iDQGs-0007Kx-En for qemu-devel@nongnu.org; Thu, 26 Sep 2019 05:41:10 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 99496C05E740; Thu, 26 Sep 2019 09:41:09 +0000 (UTC) Received: from maximlenovopc.usersys.redhat.com (unknown [10.35.206.33]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5A4DB60F9E; Thu, 26 Sep 2019 09:41:08 +0000 (UTC) Message-ID: Subject: Re: Questions about the real mode in kvm/qemu From: Maxim Levitsky To: Paolo Bonzini , Li Qiang Date: Thu, 26 Sep 2019 12:41:07 +0300 In-Reply-To: <4ed0f9ca-6cd1-fd8e-9abd-4098f85c7f9d@redhat.com> References: <644968ffb11c11fd580e96c1e67932501a633fe4.camel@redhat.com> <3d3f3a0e6e796260348c66e69e859e1901501ee8.camel@redhat.com> <23789310-35fb-8c93-44f4-532bcd34007d@redhat.com> <7c019f3a5236daaa79e67467f64cde212ad05f35.camel@redhat.com> <4ed0f9ca-6cd1-fd8e-9abd-4098f85c7f9d@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Thu, 26 Sep 2019 09:41:09 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Qemu Developers , Avi Kivity Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Thu, 2019-09-26 at 11:33 +0200, Paolo Bonzini wrote: > On 26/09/19 11:24, Maxim Levitsky wrote: > > On Thu, 2019-09-26 at 11:18 +0200, Paolo Bonzini wrote: > > > On 26/09/19 10:59, Maxim Levitsky wrote: > > > > If you mean to ask if there is a way to let guest access use no > > > > paging at all, that is access host physical addresses directly, then > > > > indeed there is no way, since regular non 'unrestricted guest' mode > > > > required both protected mode and paging, and 'unrestricted guest' > > > > requires EPT. Academically speaking it is of course possible to > > > > create paging tables that are 1:1... > > > > > > Not so academically, it's exactly what KVM does. > > > > You mean KVM uses 1:1 EPT pages and no guest paging, > > to allow guest to access host physical address space? > > No, it uses the usual HVA->GPA EPT pages and 1:1 GPA->GVA pages when EPT > is enabled and guest CR0.PG=0. This lets KVM work around the CR0.PG=1 > requirement when unrestricted guest mode. I understand now. > > Thinking more about it, I suppose that saves memory (the same EPT page > tables can now be used independent of guest CR0.PG), at the cost of > making TLB misses a little slower. Don't really understand what you mean. Isn't this always the case that EPT and guest paging are independent (at least when no nesting is involved)? Best regards, Maxim Levitsky