Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp3833336imm; Mon, 15 Oct 2018 05:05:42 -0700 (PDT) X-Google-Smtp-Source: ACcGV6068Lg2TYQmQ/90tujlmG6GXwwekkJmp1geSWzyiYTyChMvElv5Yq5Dk1MXQ48vTjr2nK1s X-Received: by 2002:a65:5bc1:: with SMTP id o1-v6mr16074734pgr.391.1539605142309; Mon, 15 Oct 2018 05:05:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539605142; cv=none; d=google.com; s=arc-20160816; b=i/CLkqQ0cNfEG1xSWHyql3Lwro1SAWvAWOwB4h6Tm/CI33TzNgUB1bAELy7YR9jejT MRNICfIXyMfKSm5Y0WLPBKQy9gz2iIPhA4/3V7/aWzW2Jm0N5ICCzZ1amdNkVIkOdG9u O5R9tSommBHc9AQ26+tRBxVBl41ZLh158vdaI5r+pSpv5vc7o6HhmoZ82GmmCOqnnjjm Em6qhQYdDtUFqEYWLsQGHkMWudhAyE7PN2c71fU9an+kqvCQf6LCiboBZEpyeVrHKeYj mwtwlWv0UfNZbAjvc9UgN/+0DNlYu0dEVqy7rFncRxpJtEN3wT7iVmn1ZaJTttNmevCo 3JfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:autocrypt:openpgp:from:references:cc:to:subject; bh=vqJOrhL+LGU4eyf5ZFg5K4RiE/HSX1tQuKyAnLV7JxI=; b=aQwIITovryy40GdA3xMj5V22T5+7bgLgY6FMbAw65fjiEcP9qqmJcVpwkn4swLywhh 5nKHfTlxJlgvJp35bb1Elwk4Qd0q1FEZuEIFDd6XNLq33hEYUcTkw2Jb4VXeCw1J6Few wR3+3djrSWMiqFo/qe9RVNsuE8PeyAIHS6t96KJ/zpNRpUtAHvPBkQVDA7W41AsUfVMu z2jqHd7eSOMBp6CG0+3l2w52pFATDAM7zuVm9w3z7HTHhd/Unv3tM373KQr7Hl6Jn190 OnDr/ybfsBnjiON4bw42kiAsowSoRkA13pQ+tmFnFBCe8pGD5ozJ/MU+BFrqaRAw5cAY 0N+g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d31-v6si10772289pla.256.2018.10.15.05.05.26; Mon, 15 Oct 2018 05:05:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726588AbeJOTuD (ORCPT + 99 others); Mon, 15 Oct 2018 15:50:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35992 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726319AbeJOTuD (ORCPT ); Mon, 15 Oct 2018 15:50:03 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BD6E33082143; Mon, 15 Oct 2018 12:05:02 +0000 (UTC) Received: from [10.36.117.209] (ovpn-117-209.ams2.redhat.com [10.36.117.209]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 54B8867C70; Mon, 15 Oct 2018 12:04:48 +0000 (UTC) Subject: Re: [PATCH V4 00/15] x86/KVM/Hyper-v: Add HV ept tlb range flush hypercall support in KVM To: lantianyu1986@gmail.com Cc: Lan Tianyu , benh@kernel.crashing.org, catalin.marinas@arm.com, christoffer.dall@arm.com, devel@linuxdriverproject.org, haiyangz@microsoft.com, hpa@zytor.com, jhogan@kernel.org, kvmarm@lists.cs.columbia.edu, kvm-ppc@vger.kernel.org, kvm@vger.kernel.org, kys@microsoft.com, linux-arm-kernel@lists.infradead.org, linux@armlinux.org, linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, linuxppc-dev@lists.ozlabs.org, marc.zyngier@arm.com, mingo@redhat.com, mpe@ellerman.id.au, paul.burton@mips.com, paulus@ozlabs.org, ralf@linux-mips.org, rkrcmar@redhat.com, sthemmin@microsoft.com, tglx@linutronix.de, will.deacon@arm.com, x86@kernel.org, michael.h.kelley@microsoft.com, vkuznets@redhat.com References: <20181013145406.4911-1-Tianyu.Lan@microsoft.com> From: Paolo Bonzini Openpgp: preference=signencrypt Autocrypt: addr=pbonzini@redhat.com; prefer-encrypt=mutual; keydata= xsEhBFRCcBIBDqDGsz4K0zZun3jh+U6Z9wNGLKQ0kSFyjN38gMqU1SfP+TUNQepFHb/Gc0E2 CxXPkIBTvYY+ZPkoTh5xF9oS1jqI8iRLzouzF8yXs3QjQIZ2SfuCxSVwlV65jotcjD2FTN04 hVopm9llFijNZpVIOGUTqzM4U55sdsCcZUluWM6x4HSOdw5F5Utxfp1wOjD/v92Lrax0hjiX DResHSt48q+8FrZzY+AUbkUS+Jm34qjswdrgsC5uxeVcLkBgWLmov2kMaMROT0YmFY6A3m1S P/kXmHDXxhe23gKb3dgwxUTpENDBGcfEzrzilWueOeUWiOcWuFOed/C3SyijBx3Av/lbCsHU Vx6pMycNTdzU1BuAroB+Y3mNEuW56Yd44jlInzG2UOwt9XjjdKkJZ1g0P9dwptwLEgTEd3Fo UdhAQyRXGYO8oROiuh+RZ1lXp6AQ4ZjoyH8WLfTLf5g1EKCTc4C1sy1vQSdzIRu3rBIjAvnC tGZADei1IExLqB3uzXKzZ1BZ+Z8hnt2og9hb7H0y8diYfEk2w3R7wEr+Ehk5NQsT2MPI2QBd wEv1/Aj1DgUHZAHzG1QN9S8wNWQ6K9DqHZTBnI1hUlkp22zCSHK/6FwUCuYp1zcAEQEAAc0f UGFvbG8gQm9uemluaSA8Ym9uemluaUBnbnUub3JnPsLBTQQTAQIAIwUCVEJ7AwIbAwcLCQgH AwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEH4VEAzNNmmxNcwOniaZVLsuy1lW/ntYCA0Caz0i sHpmecK8aWlvL9wpQCk4GlOX9L1emyYXZPmzIYB0IRqmSzAlZxi+A2qm9XOxs5gJ2xqMEXX5 FMtUH3kpkWWJeLqe7z0EoQdUI4EG988uv/tdZyqjUn2XJE+K01x7r3MkUSFz/HZKZiCvYuze VlS0NTYdUt5jBXualvAwNKfxEkrxeHjxgdFHjYWhjflahY7TNRmuqPM/Lx7wAuyoDjlYNE40 Z+Kun4/KjMbjgpcF4Nf3PJQR8qXI6p3so2qsSn91tY7DFSJO6v2HwFJkC2jU95wxfNmTEUZc znXahYbVOwCDJRuPrE5GKFd/XJU9u5hNtr/uYipHij01WXal2cce1S5mn1/HuM1yo1u8xdHy IupCd57EWI948e8BlhpujUCU2tzOb2iYS0kpmJ9/oLVZrOcSZCcCl2P0AaCAsj59z2kwQS9D du0WxUs8waso0Qq6tDEHo8yLCOJDzSz4oojTtWe4zsulVnWV+wu70AioemAT8S6JOtlu60C5 dHgQUD1Tp+ReXpDKXmjbASJx4otvW0qah3o6JaqO79tbDqIvncu3tewwp6c85uZd48JnIOh3 utBAu684nJakbbvZUGikJfxd887ATQRUQnHuAQgAx4dxXO6/Zun0eVYOnr5GRl76+2UrAAem Vv9Yfn2PbDIbxXqLff7oyVJIkw4WdhQIIvvtu5zH24iYjmdfbg8iWpP7NqxUQRUZJEWbx2CR wkMHtOmzQiQ2tSLjKh/cHeyFH68xjeLcinR7jXMrHQK+UCEw6jqi1oeZzGvfmxarUmS0uRuf fAb589AJW50kkQK9VD/9QC2FJISSUDnRC0PawGSZDXhmvITJMdD4TjYrePYhSY4uuIV02v02 8TVAaYbIhxvDY0hUQE4r8ZbGRLn52bEzaIPgl1p/adKfeOUeMReg/CkyzQpmyB1TSk8lDMxQ zCYHXAzwnGi8WU9iuE1P0wARAQABwsEzBBgBAgAJBQJUQnHuAhsMAAoJEH4VEAzNNmmxp1EO oJy0uZggJm7gZKeJ7iUpeX4eqUtqelUw6gU2daz2hE/jsxsTbC/w5piHmk1H1VWDKEM4bQBT uiJ0bfo55SWsUNN+c9hhIX+Y8LEe22izK3w7mRpvGcg+/ZRG4DEMHLP6JVsv5GMpoYwYOmHn plOzCXHvmdlW0i6SrMsBDl9rw4AtIa6bRwWLim1lQ6EM3PWifPrWSUPrPcw4OLSwFk0CPqC4 HYv/7ZnASVkR5EERFF3+6iaaVi5OgBd81F1TCvCX2BEyIDRZLJNvX3TOd5FEN+lIrl26xecz 876SvcOb5SL5SKg9/rCBufdPSjojkGFWGziHiFaYhbuI2E+NfWLJtd+ZvWAAV+O0d8vFFSvr iy9enJ8kxJwhC0ECbSKFY+W1eTIhMD3aeAKY90drozWEyHhENf4l/V+Ja5vOnW+gCDQkGt2Y 1lJAPPSIqZKvHzGShdh8DduC0U3xYkfbGAUvbxeepjgzp0uEnBXfPTy09JGpgWbg0w91GyfT /ujKaGd4vxG2Ei+MMNDmS1SMx7wu0evvQ5kT9NPzyq8R2GIhVSiAd2jioGuTjX6AZCFv3ToO 53DliFMkVTecLptsXaesuUHgL9dKIfvpm+rNXRn9wAwGjk0X/A== Message-ID: Date: Mon, 15 Oct 2018 14:04:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20181013145406.4911-1-Tianyu.Lan@microsoft.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.42]); Mon, 15 Oct 2018 12:05:03 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13/10/2018 16:53, lantianyu1986@gmail.com wrote: > From: Lan Tianyu > > For nested memory virtualization, Hyper-v doesn't set write-protect > L1 hypervisor EPT page directory and page table node to track changes > while it relies on guest to tell it changes via HvFlushGuestAddressLlist > hypercall. HvFlushGuestAddressLlist hypercall provides a way to flush > EPT page table with ranges which are specified by L1 hypervisor. > > If L1 hypervisor uses INVEPT or HvFlushGuestAddressSpace hypercall to > flush EPT tlb, Hyper-V will invalidate associated EPT shadow page table > and sync L1's EPT table when next EPT page fault is triggered. > HvFlushGuestAddressLlist hypercall helps to avoid such redundant EPT > page fault and synchronization of shadow page table. So I just told you that the first part is well understood but I must retract that; after carefully reviewing the whole series, I think one of us is actually very confused. I am not afraid to say it can be me, but my understanding is that you're passing L1 GPAs to the hypercall and instead the spec says it expects L2 GPAs. (Consider that, because KVM's shadow paging code is shared between nested EPT and !EPT cases, every time you see gpa/gfn in the code it is for L1, while nested EPT GPAs are really what the code calls gva.) What's going on? Paolo