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.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham 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 091ACC433E0 for ; Wed, 27 May 2020 08:45:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E2ECF2078C for ; Wed, 27 May 2020 08:45:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388248AbgE0IpD (ORCPT ); Wed, 27 May 2020 04:45:03 -0400 Received: from foss.arm.com ([217.140.110.172]:34092 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388211AbgE0IpC (ORCPT ); Wed, 27 May 2020 04:45:02 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0F0CF30E; Wed, 27 May 2020 01:45:02 -0700 (PDT) Received: from [192.168.0.110] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 21F9B3F6C4; Wed, 27 May 2020 01:45:00 -0700 (PDT) Subject: Re: [PATCH 03/26] KVM: arm64: Factor out stage 2 page table data from struct kvm To: Marc Zyngier Cc: James Morse , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Andre Przywara , Christoffer Dall , Dave Martin , Jintack Lim , George Cherian , "Zengtao (B)" , Will Deacon , Catalin Marinas , Mark Rutland , Julien Thierry , Suzuki K Poulose References: <20200422120050.3693593-1-maz@kernel.org> <20200422120050.3693593-4-maz@kernel.org> <76d811eb-b304-c49f-1f21-fe9d95112a28@arm.com> <6518439c-65b7-1e87-a21d-a053d75c0514@arm.com> From: Alexandru Elisei Message-ID: <91b6b062-e39d-a672-52e4-40532068a02e@arm.com> Date: Wed, 27 May 2020 09:45:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Hi Marc, On 5/27/20 9:41 AM, Marc Zyngier wrote: > Hi Alex, > > On 2020-05-12 17:53, Alexandru Elisei wrote: >> Hi, >> >> On 5/12/20 12:17 PM, James Morse wrote: >>> Hi Alex, Marc, >>> >>> (just on this last_vcpu_ran thing...) >>> >>> On 11/05/2020 17:38, Alexandru Elisei wrote: >>>> On 4/22/20 1:00 PM, Marc Zyngier wrote: >>>>> From: Christoffer Dall >>>>> >>>>> As we are about to reuse our stage 2 page table manipulation code for >>>>> shadow stage 2 page tables in the context of nested virtualization, we >>>>> are going to manage multiple stage 2 page tables for a single VM. >>>>> >>>>> This requires some pretty invasive changes to our data structures, >>>>> which moves the vmid and pgd pointers into a separate structure and >>>>> change pretty much all of our mmu code to operate on this structure >>>>> instead. >>>>> >>>>> The new structure is called struct kvm_s2_mmu. >>>>> >>>>> There is no intended functional change by this patch alone. >>>>> diff --git a/arch/arm64/include/asm/kvm_host.h >>>>> b/arch/arm64/include/asm/kvm_host.h >>>>> index 7dd8fefa6aecd..664a5d92ae9b8 100644 >>>>> --- a/arch/arm64/include/asm/kvm_host.h >>>>> +++ b/arch/arm64/include/asm/kvm_host.h >>>>> @@ -63,19 +63,32 @@ struct kvm_vmid { >>>>>      u32    vmid; >>>>>  }; >>>>> >>>>> -struct kvm_arch { >>>>> +struct kvm_s2_mmu { >>>>>      struct kvm_vmid vmid; >>>>> >>>>> -    /* stage2 entry level table */ >>>>> -    pgd_t *pgd; >>>>> -    phys_addr_t pgd_phys; >>>>> - >>>>> -    /* VTCR_EL2 value for this VM */ >>>>> -    u64    vtcr; >>>>> +    /* >>>>> +     * stage2 entry level table >>>>> +     * >>>>> +     * Two kvm_s2_mmu structures in the same VM can point to the same pgd >>>>> +     * here.  This happens when running a non-VHE guest hypervisor which >>>>> +     * uses the canonical stage 2 page table for both vEL2 and for vEL1/0 >>>>> +     * with vHCR_EL2.VM == 0. >>>> It makes more sense to me to say that a non-VHE guest hypervisor will use the >>>> canonical stage *1* page table when running at EL2 >>> Can KVM say anything about stage1? Its totally under the the guests control >>> even at vEL2... >> >> It just occurred to me that "canonical stage 2 page table" refers to the L0 >> hypervisor stage 2, not to the L1 hypervisor stage 2. If you don't mind my >> suggestion, perhaps the comment can be slightly improved to avoid any confusion? >> Maybe something along the lines of "[..] This happens when running a >> non-VHE guest >> hypervisor, in which case we use the canonical stage 2 page table for both vEL2 >> and for vEL1/0 with vHCR_EL2.VM == 0". > > If the confusion stems from the lack of guest stage-2, how about: > > "This happens when running a guest using a translation regime that isn't >  affected by its own stage-2 translation, such as a non-VHE hypervisor >  running at vEL2, or for vEL1/EL0 with vHCR_EL2.VM == 0. In that case, >  we use the canonical stage-2 page tables." > > instead? Does this lift the ambiguity? Yes, that's perfect. Thanks, Alex > > Thanks, > >         M.