[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <396423df-5c30-67f6-fcba-c041c08eef7e@redhat.com>
Date: Wed, 7 Apr 2021 17:30:05 +0200
From: David Hildenbrand <david@...hat.com>
To: Catalin Marinas <catalin.marinas@....com>,
Steven Price <steven.price@....com>
Cc: Mark Rutland <mark.rutland@....com>,
Peter Maydell <peter.maydell@...aro.org>,
"Dr. David Alan Gilbert" <dgilbert@...hat.com>,
Andrew Jones <drjones@...hat.com>, Haibo Xu <Haibo.Xu@....com>,
Suzuki K Poulose <suzuki.poulose@....com>,
qemu-devel@...gnu.org, Marc Zyngier <maz@...nel.org>,
Juan Quintela <quintela@...hat.com>,
Richard Henderson <richard.henderson@...aro.org>,
linux-kernel@...r.kernel.org, Dave Martin <Dave.Martin@....com>,
James Morse <james.morse@....com>,
linux-arm-kernel@...ts.infradead.org,
Thomas Gleixner <tglx@...utronix.de>,
Will Deacon <will@...nel.org>, kvmarm@...ts.cs.columbia.edu,
Julien Thierry <julien.thierry.kdev@...il.com>
Subject: Re: [PATCH v10 2/6] arm64: kvm: Introduce MTE VM feature
On 07.04.21 17:14, Catalin Marinas wrote:
> On Wed, Apr 07, 2021 at 11:20:18AM +0100, Steven Price wrote:
>> On 31/03/2021 19:43, Catalin Marinas wrote:
>>> When a slot is added by the VMM, if it asked for MTE in guest (I guess
>>> that's an opt-in by the VMM, haven't checked the other patches), can we
>>> reject it if it's is going to be mapped as Normal Cacheable but it is a
>>> ZONE_DEVICE (i.e. !kvm_is_device_pfn() + one of David's suggestions to
>>> check for ZONE_DEVICE)? This way we don't need to do more expensive
>>> checks in set_pte_at().
>>
>> The problem is that KVM allows the VMM to change the memory backing a slot
>> while the guest is running. This is obviously useful for the likes of
>> migration, but ultimately means that even if you were to do checks at the
>> time of slot creation, you would need to repeat the checks at set_pte_at()
>> time to ensure a mischievous VMM didn't swap the page for a problematic one.
>
> Does changing the slot require some KVM API call? Can we intercept it
> and do the checks there?
User space can simply mmap(MAP_FIXED) the user space area registered in
a KVM memory slot. You cannot really intercept that. You can only check
in the KVM MMU code at fault time that the VMA which you hold in your
hands is still in a proper state. The KVM MMU is synchronous, which
means that updates to the VMA layout are reflected in the KVM MMU page
tables -- e.g., via mmu notifier calls.
E.g., in s390x code we cannot handle VMAs with gigantic pages. We check
that when faulting (creating the links in the page table) via __gmap_link().
You could either check the page itself (ZONE_DEVICE) or might even be
able to check via the VMA/file.
--
Thanks,
David / dhildenb
Powered by blists - more mailing lists