Re: [PATCH] KVM: arm64: permit MAP_SHARED mappings with MTE enabled

From: Cornelia Huck <cohuck@redhat.com>
To: Steven Price <steven.price@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>
Cc: Peter Collingbourne <pcc@google.com>,
	kvmarm@lists.cs.columbia.edu, Marc Zyngier <maz@kernel.org>,
	kvm@vger.kernel.org, Andy Lutomirski <luto@amacapital.net>,
	linux-arm-kernel@lists.infradead.org,
	Michael Roth <michael.roth@amd.com>,
	Chao Peng <chao.p.peng@linux.intel.com>,
	Will Deacon <will@kernel.org>,
	Evgenii Stepanov <eugenis@google.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Gavin Shan <gshan@redhat.com>, Eric Auger <eric.auger@redhat.com>,
	Peter Xu <peterx@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH] KVM: arm64: permit MAP_SHARED mappings with MTE enabled
Date: Fri, 08 Jul 2022 15:03:34 +0200	[thread overview]
Message-ID: <87bktz7o49.fsf@redhat.com> (raw)
In-Reply-To: <b91ae197-d191-2204-aab5-21a0aabded69@arm.com>

On Mon, Jul 04 2022, Steven Price <steven.price@arm.com> wrote:

> On 04/07/2022 13:19, Cornelia Huck wrote:
>> On Mon, Jul 04 2022, Steven Price <steven.price@arm.com> wrote:
>> 
>>> On 29/06/2022 09:45, Catalin Marinas wrote:
>>>> On Mon, Jun 27, 2022 at 05:55:33PM +0200, Cornelia Huck wrote:
>>>
>>>>> [Postcopy needs a different interface, I guess, so that the migration
>>>>> target can atomically place a received page and its metadata. I see
>>>>> https://lore.kernel.org/all/CAJc+Z1FZxSYB_zJit4+0uTR-88VqQL+-01XNMSEfua-dXDy6Wg@mail.gmail.com/;
>>>>> has there been any follow-up?]
>>>>
>>>> I don't follow the qemu list, so I wasn't even aware of that thread. But
>>>> postcopy, the VMM needs to ensure that both the data and tags are up to
>>>> date before mapping such page into the guest address space.
>>>>
>>>
>>> I'm not sure I see how atomically updating data+tags is different from
>>> the existing issues around atomically updating the data. The VMM needs
>>> to ensure that the guest doesn't see the page before all the data+all
>>> the tags are written. It does mean lazy setting of the tags isn't
>>> possible in the VMM, but I'm not sure that's a worthwhile thing anyway.
>>> Perhaps I'm missing something?
>> 
>> For postcopy, we basically want to fault in any not-yet-migrated page
>> via uffd once the guest accesses it. We only get the page data that way,
>> though, not the tag. I'm wondering whether we'd need a 'page+metadata'
>> uffd mode; not sure if that makes sense. Otherwise, we'd need to stop
>> the guest while grabbing the tags for the page as well, and stopping is
>> the thing we want to avoid here.
>
> Ah, I think I see now. UFFDIO_COPY atomically populates the (data) page
> and ensures that no thread will see the partially populated page. But
> there's currently no way of doing that with tags as well.

Nod.

>
> I'd not looked at the implementation of userfaultfd before and I'd
> assumed it avoided the need for an 'atomic' operation like this. But
> apparently not! AFAICT either a new ioctl would be needed (which can
> take a tag buffer) or a new flag to UFFDIO_COPY which would tighten the
> alignment requirements of `src` and would copy the tags along with the data.

I was thinking about a new flag that implies "copy metadata"; not sure
how we would get the same atomicity with a separate ioctl. I've only
just started looking at userfaultfd, though, and I might be on a wrong
track... One thing I'd like to avoid is having something that is too
ARM-specific, I think there are other architecture features that might
have similar issues.

Maybe someone more familiar with uffd and/or postcopy can chime in?