Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [RFC PATCH 2/2] arm64: kvm: Introduce MTE VCPU feature
To:     Steven Price <steven.price@arm.com>
Cc:     Catalin Marinas <catalin.marinas@arm.com>,
        Marc Zyngier <maz@kernel.org>, Will Deacon <will@kernel.org>,
        Julien Thierry <julien.thierry.kdev@gmail.com>,
        Suzuki Poulose <Suzuki.Poulose@arm.com>,
        "kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Dave P Martin <Dave.Martin@arm.com>,
        Mark Rutland <Mark.Rutland@arm.com>,
        Thomas Gleixner <tglx@linutronix.de>
References: <20200617123844.29960-1-steven.price@arm.com>
 <20200617123844.29960-3-steven.price@arm.com> <20200617143809.GF5388@gaia>
 <9d4ef6cf-2333-83b8-c555-e70b99b95b28@arm.com>
From:   James Morse <james.morse@arm.com>
Message-ID: <c2883b2b-6c71-f5ee-74b7-4e4d08d2183c@arm.com>
Date:   Fri, 26 Jun 2020 17:40:51 +0100
User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <9d4ef6cf-2333-83b8-c555-e70b99b95b28@arm.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Steve,

On 17/06/2020 16:34, Steven Price wrote:
> On 17/06/2020 15:38, Catalin Marinas wrote:
>> On Wed, Jun 17, 2020 at 01:38:44PM +0100, Steven Price wrote:
>>> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
>>> index e3b9ee268823..040a7fffaa93 100644
>>> --- a/virt/kvm/arm/mmu.c
>>> +++ b/virt/kvm/arm/mmu.c
>>> @@ -1783,6 +1783,17 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t
>>> fault_ipa,
>>>               vma_pagesize = PMD_SIZE;
>>>       }
>>>   +    if (system_supports_mte() && kvm->arch.vcpu_has_mte) {
>>> +        /*
>>> +         * VM will be able to see the page's tags, so we must ensure
>>> +         * they have been initialised.
>>> +         */
>>> +        struct page *page = pfn_to_page(pfn);
>>> +
>>> +        if (!test_and_set_bit(PG_mte_tagged, &page->flags))
>>> +            mte_clear_page_tags(page_address(page), page_size(page));
>>> +    }
>>
>> Are all the guest pages always mapped via a Stage 2 fault? It may be
>> better if we did that via kvm_set_spte_hva().

> I was under the impression that pages are always faulted into the stage 2, but I have to
> admit I'm not 100% sure about that.

I think there is only one case: VMA with VM_PFNMAP set will get pre-populated during
kvm_arch_prepare_memory_region(), but they are always made device at stage2, so MTE isn't
a concern there.


> kvm_set_spte_hva() may be more appropriate, although on first look I don't understand how
> that function deals with huge pages. Is it actually called for normal mappings or only for
> changes due to the likes of KSM?

It looks like its only called through set_pte_at_notify(), which is used by things like
KSM/COW that change a mapping, and really don't want to fault it a second time. I guess
they are only for PAGE_SIZE mappings.

Other mapping sizes would get faulted in by user_mem_abort().


I think this should happen in the same places as we clean new pages to PoC, as that is
also an additional piece of maintenance KVM has to do that the host's stage 1 doesn't.

You may be able to rename clean_dcache_guest_page() to encompass maintenance that we need
when a page is accessible to a different EL1.


Thanks,

James