From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yb1-f201.google.com (mail-yb1-f201.google.com [209.85.219.201]) (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 409DA3D3A0 for ; Wed, 13 Mar 2024 14:48:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710341335; cv=none; b=Cdg/AgBNHYXCOEEoG3fCjkdYnEdGi3qW3qnhLfp2n4eHklFWkHOYRpodq1wGuFOvytOSkVOTvQGF2qluInV+vzKGxC7IAIaBBXI6/MLjTE8HMm7QR0W+oS6HLuzI0vdU3QiAfhlIrH/ZVN998BGGnQYlG2ksc4CqLkzW1fu9VZA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710341335; c=relaxed/simple; bh=wYEkrJjWGVx0jUWCjYrd/YRNNm9Cl5QCj3a74RDOIV4=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=HWLFWXBL0SFBkIqewPjdIQL7ZluYvucG+YpHImoDttGG8J97GHJREJWfNCwfqnsz2W45SOhW0eU07bUzs1LnvO3RIsBqKJcKAQDGE2xtbFVGXlY3eU2J1854vJUs4aW+0WnMam8ildfHSR/89rxBYiYqpIvuuvyUGqlaUwZJ4ZE= 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=fiTcRvfX; arc=none smtp.client-ip=209.85.219.201 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="fiTcRvfX" Received: by mail-yb1-f201.google.com with SMTP id 3f1490d57ef6-dd0ae66422fso2061700276.0 for ; Wed, 13 Mar 2024 07:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1710341333; x=1710946133; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=yZFsDiSg8Veluka6E47FAf82LDK/U1v1gTIe6ZTkV+A=; b=fiTcRvfXD0T2fdrvNJoPF8f7tezf99bCT8HVRom32qbxhpubkE4z6+QWzVVkzHBo5b wEpVHwOw4AeU3vgio7YI8BjR1JpRE/S2kk6xsg/7dGIRKK4X9H+X/MKGFW83+s+z9l4j btjTj+iacauQI3mmZewJfVuIaPa68IMDlIFAHqbliSP5thKGiSPlQa6+xYfDTq5xc+Fi G8kvzNTvJD0rvV5Qy5+pItUlS2DZSqpNyjKc0DRCfIF7uNQxg+tQViuD7FI2OeBHtMg6 rRkpFQbK+auso86TUp3XMowC2MMZzP3SZM2fc6oGsr8GLW/swWyXNbxjDagwdCpxnkfa V8Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710341333; x=1710946133; h=content-transfer-encoding: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=yZFsDiSg8Veluka6E47FAf82LDK/U1v1gTIe6ZTkV+A=; b=koI5fOT8vzu4MUZ55VhRvsZl4en5ebJ4rbuZkmIsQmAtUp6jTMCb2870MFwiuAiWTu c6ahunlDXa+boiA8B0MBFS9qS3sd8DtrXaUrwp1EVhwpjMuF9b0XSEvgDQAvCZFEGBZr 2GYTXiWdNWOHUWd1AMJYnVWNBRfZYlDSHR4wWPz1Vn41u7fXOUbeE3uNphx5QZkWtC6Y aRhukEo1nMqmJnUTQyrhvaGipZC/4k1h3bmr9y50jaEMVLuGdkzcqyisHEXAR7gHTt/8 rEiuqeSmrKoTvmX4u89LRSjhCfSRCxSldf238V3YkzevkGUrZTDIMGzIpVKe0nVO5EsK GZTg== X-Forwarded-Encrypted: i=1; AJvYcCXiLajxZ5awA2p4meuyb5mLXyVptDodVgfhGBs6happYTDWTpFZ+cKXc2YHGb0g+o3gNpGflwZSqe3XKgt1WI1hKjMlIltfZPvW+YA2 X-Gm-Message-State: AOJu0Yxm47XO0+0IBGXziQgxKbaH+g6r3XRsj3E0fgKrRVsRFWXRBQ6I GH/7NnDNjHaX4QlBeDTklr+w9Y8Q6qZyrjAvxaVTdBVvikX+7I+4kL/D6VIW+DEYLpTbnPEK4Dg jRA== X-Google-Smtp-Source: AGHT+IHgpPoNg9mBT3unR5ry0NDCq89tXvMg05S2JkM5aQGWQRzEQ3Jm9vXfbQ5VGa1cuXTitkvbJZ34Vco= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a5b:388:0:b0:dcc:5463:49a8 with SMTP id k8-20020a5b0388000000b00dcc546349a8mr522047ybp.6.1710341333372; Wed, 13 Mar 2024 07:48:53 -0700 (PDT) Date: Wed, 13 Mar 2024 07:48:51 -0700 In-Reply-To: <0b109bc4-ee4c-4f13-996f-b89fbee09c0b@amd.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20240229025759.1187910-1-stevensd@google.com> <72285e50-6ffc-4f24-b97b-8c381b1ddf8e@amd.com> <0b109bc4-ee4c-4f13-996f-b89fbee09c0b@amd.com> Message-ID: Subject: Re: [PATCH v11 0/8] KVM: allow mapping non-refcounted pages From: Sean Christopherson To: "Christian =?utf-8?B?S8O2bmln?=" Cc: David Stevens , Christoph Hellwig , Paolo Bonzini , Yu Zhang , Isaku Yamahata , Zhi Wang , Maxim Levitsky , kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 13, 2024, Christian K=C3=B6nig wrote: > Am 13.03.24 um 14:34 schrieb Sean Christopherson: > > On Wed, Mar 13, 2024, Christian K=C3=B6nig wrote: > > > And when you have either of those two functionalities the requirement= to add > > > a long term reference to the struct page goes away completely. So whe= n this > > > is done right you don't need to grab a reference in the first place. > > The KVM issue that this series is solving isn't that KVM grabs a refere= nce, it's > > that KVM assumes that any non-reserved pfn that is backed by "struct pa= ge" is > > refcounted. >=20 > Well why does it assumes that? When you have a MMU notifier that seems > unnecessary. Indeed, it's legacy code that we're trying to clean up. It's the bulk of t= his series. > > What Christoph is objecting to is that, in this series, KVM is explicit= ly adding > > support for mapping non-compound (huge)pages into KVM guests. David is= arguing > > that Christoph's objection to _KVM_ adding support is unfair, because t= he real > > problem is that the kernel already maps such pages into host userspace.= I.e. if > > the userspace mapping ceases to exist, then there are no mappings for K= VM to follow > > and propagate to KVM's stage-2 page tables. >=20 > And I have to agree with Christoph that this doesn't make much sense. KVM > should *never* map (huge) pages from VMAs marked with VM_PFNMAP into KVM > guests in the first place. >=20 > What it should do instead is to mirror the PFN from the host page tables > into the guest page tables. That's exactly what this series does. Christoph is objecting to KVM playin= g nice with non-compound hugepages, as he feels that such mappings should not exis= t *anywhere*. I.e. Christoph is (implicitly) saying that instead of modifying KVM to play= nice, we should instead fix the TTM allocations. And David pointed out that that= was tried and got NAK'd.