From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f202.google.com (mail-yw1-f202.google.com [209.85.128.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F0BCB6F2F1 for ; Thu, 20 Jun 2024 22:32:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718922751; cv=none; b=hoRwBXBliwNvZD4iMxC1RmsMfQ6fH3Gdbk4dXKflCXuU5ajCBB9dwEP0xqm2FdPDVVLjDut0YqZFxBAi8oCNVgdhx9/eGwd4aU+J13ctPUK9FD0xViIYGrbWHdYH+nTCe7RBanR2uP+EGSaemM5DDvHz7tJF1+la550WSuj2LRg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718922751; c=relaxed/simple; bh=wPyrfyOcJKrFlQqdsvbVInKDWmVrmJ7EXk00664mnVY=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=bbIv6gg2bnb+xEg5TY876Hhe0JH4LUZ9jV+aDdh3PTXsXCChJiG8d17grE3Y+gPXYe5efTBmcdTj09zOeDtQreVTEkbkuddUjO0zljd0D6Ba1W9u5Mjck+GPVuQsbqicCdnzqZZI0tfz6OLkV3m77GMdKmitBnKY+22qFBwSvpE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=ziWgiCQs; arc=none smtp.client-ip=209.85.128.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ziWgiCQs" Received: by mail-yw1-f202.google.com with SMTP id 00721157ae682-63bf23f8fbcso25775837b3.0 for ; Thu, 20 Jun 2024 15:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1718922749; x=1719527549; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=auxotihlkK8h83W2bzIbhNSOdi4xEkdwqnFVqelIJic=; b=ziWgiCQsN9kHQVwWz8Jd4IxEBbuqnWoj8jhuS3W+HMzXKnyaXj1Y7wW9Odo/BEkVXs WOHDy9T3CvcmONF+9FL8ZxJM7EJ+f9wHhnLJly+WbDucpb7feu9MfCYbiqkyRrL8o6dF pKV04Rn/3VVE+BQwZaKhb3kDrSgMIWT9KHajvToounQ+NkOffF6IHQ0Xybr6mCz7+beX h6Mytig4cQZtgcHnC3kKSveZ6tBEDqepaA4iXjqa0oJKLngkhHHUFI5PVZUYn2yLpotE iM8x0bdOAcQ2fYQzEWFCHJfAXTuhtoOk/M6Aoj5lNFyopW1lqj+32WX0dg3Nd5qCYc1C AA+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718922749; x=1719527549; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=auxotihlkK8h83W2bzIbhNSOdi4xEkdwqnFVqelIJic=; b=Kmj359BHh0wFOLq3rMsYZGQqglbSfREKJMS/b8FnpxG0omDj32Z0zzCGFnVoPB47U7 wXRQvK21L1p8+50kJxZOzdrJxcRltABA1b+IMHV3xfYCyETIz2c2X4l9ozTtKki3Zsaz AN4HrWhf7ADOcw/b3etIpg2MrPZc9vy+wJo4Xw66OEe3Oq2s+ZCGiotE0eWAda6ZMPQr K4bAkASViLrGZlG8R/lzXJOukxfCwtOi3zPwLgnQC313cLw5j7f9QB61Nk9e7TIyjh6p L8/s3iLoL1/2+VqIvOXMQB6W7Beu00sejOK7VypZ/hEzsi28J7QTae9XRc/LhgaPNNAp 1dlQ== X-Forwarded-Encrypted: i=1; AJvYcCVAxzciVnjFop9rdslh3eUY+BkBAtqx+YUst70bNgS+kwQHRP50zXf7sXbzRYCw6jup6TFltqCfoKzzhxzn4uq558rI X-Gm-Message-State: AOJu0YwuOQbn3h1wnE4qN1iem4DjEZI5kEqlnsbymtUJdy41hR71aV9l 9cNL80w+Kka7ZIfkyp1QiajM8izFN7Nu9/T+4IIvEME5Nf3sAHT8DbGh7JLtYCP/JwocsdNz4Rq T0Q== X-Google-Smtp-Source: AGHT+IGHcNRLshBOMyztBLTs8rVKhKRXiJZQJYiLLVyOYcXhh1aFZDp6gOCGM/6iHRYpAGgEpAN5Al5CfjI= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:690c:6105:b0:62f:5d17:3628 with SMTP id 00721157ae682-63a8ae564c0mr15344897b3.0.1718922748971; Thu, 20 Jun 2024 15:32:28 -0700 (PDT) Date: Thu, 20 Jun 2024 15:32:27 -0700 In-Reply-To: <53d1e7c5-3e77-467b-be33-a618c3bb6cb3@redhat.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20240620135540.GG2494510@nvidia.com> <6d7b180a-9f80-43a4-a4cc-fd79a45d7571@redhat.com> <20240620142956.GI2494510@nvidia.com> <385a5692-ffc8-455e-b371-0449b828b637@redhat.com> <20240620163626.GK2494510@nvidia.com> <66a285fc-e54e-4247-8801-e7e17ad795a6@redhat.com> <53d1e7c5-3e77-467b-be33-a618c3bb6cb3@redhat.com> Message-ID: Subject: Re: [PATCH RFC 0/5] mm/gup: Introduce exclusive GUP pinning From: Sean Christopherson To: David Hildenbrand Cc: Jason Gunthorpe , Fuad Tabba , Christoph Hellwig , John Hubbard , Elliot Berman , Andrew Morton , Shuah Khan , Matthew Wilcox , maz@kernel.org, kvm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, pbonzini@redhat.com Content-Type: text/plain; charset="us-ascii" On Thu, Jun 20, 2024, David Hildenbrand wrote: > On 20.06.24 22:30, Sean Christopherson wrote: > > On Thu, Jun 20, 2024, David Hildenbrand wrote: > > > On 20.06.24 18:36, Jason Gunthorpe wrote: > > > > On Thu, Jun 20, 2024 at 04:45:08PM +0200, David Hildenbrand wrote: > > > > > > > > > If we could disallow pinning any shared pages, that would make life a lot > > > > > easier, but I think there were reasons for why we might require it. To > > > > > convert shared->private, simply unmap that folio (only the shared parts > > > > > could possibly be mapped) from all user page tables. > > > > > > > > IMHO it should be reasonable to make it work like ZONE_MOVABLE and > > > > FOLL_LONGTERM. Making a shared page private is really no different > > > > from moving it. > > > > > > > > And if you have built a VMM that uses VMA mapped shared pages and > > > > short-term pinning then you should really also ensure that the VM is > > > > aware when the pins go away. For instance if you are doing some virtio > > > > thing with O_DIRECT pinning then the guest will know the pins are gone > > > > when it observes virtio completions. > > > > > > > > In this way making private is just like moving, we unmap the page and > > > > then drive the refcount to zero, then move it. > > > Yes, but here is the catch: what if a single shared subpage of a large folio > > > is (validly) longterm pinned and you want to convert another shared subpage > > > to private? > > > > > > Sure, we can unmap the whole large folio (including all shared parts) before > > > the conversion, just like we would do for migration. But we cannot detect > > > that nobody pinned that subpage that we want to convert to private. > > > > > > Core-mm is not, and will not, track pins per subpage. > > > > > > So I only see two options: > > > > > > a) Disallow long-term pinning. That means, we can, with a bit of wait, > > > always convert subpages shared->private after unmapping them and > > > waiting for the short-term pin to go away. Not too bad, and we > > > already have other mechanisms disallow long-term pinnings (especially > > > writable fs ones!). > > > > I don't think disallowing _just_ long-term GUP will suffice, if we go the "disallow > > GUP" route than I think it needs to disallow GUP, period. Like the whole "GUP > > writes to file-back memory" issue[*], which I think you're alluding to, short-term > > GUP is also problematic. But unlike file-backed memory, for TDX and SNP (and I > > think pKVM), a single rogue access has a high probability of being fatal to the > > entire system. > > Disallowing short-term should work, in theory, because the By "short-term", I assume you mean "long-term"? Or am I more lost than I realize? > writes-to-fileback has different issues (the PIN is not the problem but the > dirtying). > > It's more related us not allowing long-term pins for FSDAX pages, because > the lifetime of these pages is determined by the FS. > > What we would do is > > 1) Unmap the large folio completely and make any refaults block. > -> No new pins can pop up > > 2) If the folio is pinned, busy-wait until all the short-term pins are > gone. This is the step that concerns me. "Relatively short time" is, well, relative. Hmm, though I suppose if userspace managed to map a shared page into something that pins the page, and can't force an unpin, e.g. by stopping I/O?, then either there's a host userspace bug or a guest bug, and so effectively hanging the vCPU that is waiting for the conversion to complete is ok. > 3) Safely convert the relevant subpage from shared -> private > > Not saying it's the best approach, but it should be doable.