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=-5.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,PLING_QUERY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 71156C433DF for ; Wed, 14 Oct 2020 08:27:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1CB24212CC for ; Wed, 14 Oct 2020 08:27:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="adFQLO+6" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727416AbgJNI11 (ORCPT ); Wed, 14 Oct 2020 04:27:27 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:22807 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726554AbgJNI10 (ORCPT ); Wed, 14 Oct 2020 04:27:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1602664047; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=x4g3JzaJkXiHhjCbtynOGjqdUPHPFvNBFEwUL+601iw=; b=adFQLO+6HXybCOmTllml2MZPfdYBm3gMpVLkF6pt6TT6R90d0dqy+KWWOTIY/Gh7qOAqvH EvZbnvER5mxBq3gzkN8N1QmQOuDJXWswZ3MgOqNcw/xhx17WuF1kcQm4JETYZUY03NELFY 1jBIievdg4ue6ou1810Wlex1brYiUcc= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-155-_nQOPrYkPmuJLiwPNQFouQ-1; Wed, 14 Oct 2020 04:27:25 -0400 X-MC-Unique: _nQOPrYkPmuJLiwPNQFouQ-1 Received: by mail-ed1-f70.google.com with SMTP id e14so913604edk.2 for ; Wed, 14 Oct 2020 01:27:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=x4g3JzaJkXiHhjCbtynOGjqdUPHPFvNBFEwUL+601iw=; b=rwGiEqBBL8FhDIJ3jch/bHATaP5xpnc2MPMXlFkACIzrh8RKlpLIhwoixwb6fJrkG1 t1UwV0kkt95ZMNmXBZQjKH6FiojQA5mR6kzSthBzQl/belsjsge67Zp+/kHXBS7EkSRm ZHiNmG6i1qQTbDR+uaFTArYfpj5Xz0Fhifeqs376bXhNoqCA0wmjoB23JeYEy+FCXkFJ Z8lryKioO1AA9z/HBGqho/YryQKF2DGEhuYibT28+zrJHXnvoX5qjhNqbCo7G02799kC usiHXtb+fTpSFiME2koAYlhsQJGQDYmCfy/+FgWjAWNAUEjJmwPoemBFBDRHyelq4ib/ QV1w== X-Gm-Message-State: AOAM533zDkxP2ioxfTOwuehgl0GPrMt0tyJ0xCG5PzuXDZKtVKD8n+5z AH+uJdEvtSaq8822xXUiMT9DcbqJF3/ptoOgOtdlD6QW2E878AojMtBHqqBBfE0vF4qNRRXcvJ5 eFlgO1BLTrhzu X-Received: by 2002:aa7:de06:: with SMTP id h6mr3908472edv.31.1602664044092; Wed, 14 Oct 2020 01:27:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw0qpIx7WA12LFk5RAxsrrUKAYr738RykIwdqdF0x1Sm/2twJVXzbmig9JdADFGNPyRu/33GA== X-Received: by 2002:aa7:de06:: with SMTP id h6mr3908439edv.31.1602664043555; Wed, 14 Oct 2020 01:27:23 -0700 (PDT) Received: from ?IPv6:2001:b07:6468:f312:e5f7:db3b:55ea:7337? ([2001:b07:6468:f312:e5f7:db3b:55ea:7337]) by smtp.gmail.com with ESMTPSA id cw15sm1245419ejb.47.2020.10.14.01.27.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2020 01:27:22 -0700 (PDT) Subject: Re: Why guest physical addresses are not the same as the corresponding host virtual addresses in QEMU/KVM? Thanks! To: harry harry , Sean Christopherson Cc: Maxim Levitsky , qemu-devel@nongnu.org, mathieu.tarral@protonmail.com, stefanha@redhat.com, libvir-list@redhat.com, kvm@vger.kernel.org References: <47ead258320536d00f9f32891da3810040875aff.camel@redhat.com> <20201012165428.GD26135@linux.intel.com> <20201013045245.GA11344@linux.intel.com> From: Paolo Bonzini Message-ID: <24cdf8f2-7dc7-1232-8d78-86f9b4b8eda3@redhat.com> Date: Wed, 14 Oct 2020 10:27:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On 13/10/20 22:36, harry harry wrote: > Hi Paolo and Sean, > > Thanks much for your prompt replies and clear explanations. > > On Tue, Oct 13, 2020 at 2:43 AM Paolo Bonzini wrote: >> >> No, the logic to find the HPA with a given HVA is the same as the >> hardware logic to translate HVA -> HPA. That is it uses the host >> "regular" page tables, not the nested page tables. >> >> In order to translate GPA to HPA, instead, KVM does not use the nested >> page tables. > > I am curious why KVM does not directly use GPAs as HVAs and leverage > nested page tables to translate HVAs (i.e., GPAs) to HPAs? GPAs and HVAs are different things. In fact I'm not aware of any hypervisor that uses HVA==GPA. On 32-bit x86 systems HVAs are 32-bit (obviously) but GPAs are 36-bit. In the case of KVM, HVAs are controlled by the rest of Linux; for example, when you do "mmap" to allocate guest memory you cannot ask the OS to return the guest memory at the exact HVA that is needed by the guest. There could be something else at that HVA (or you don't want anything at that HVA: GPA 0 is valid, but HVA 0 is the NULL pointer!). There's also cases where the same memory appears in multiple places in the guest memory map (aliasing). Paolo