From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f200.google.com (mail-pl1-f200.google.com [209.85.214.200]) (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 9EEFF1C5799 for ; Mon, 3 Aug 2026 13:40:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.200 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785764459; cv=none; b=cMOr2LzlrBr9w0FaZfVTYrsxnEGoH5nT6GQwfRxzIPrU6YP0kYMHfemR5PvYOdBMTVQDJs+iYXB9SOSKhA8uRkhx+OeKfF/RvHgfIC3FBFNWBDWpJAEFjEaGJouHPjnbcdols22RB0MibzAlkA4MYwe1u8DRWEZK8pak2m66Iis= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785764459; c=relaxed/simple; bh=rY2g8///6Z3SBkyz4tupoNnDNJ74RHWhu0kftawIifg=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=LG9z88RlDzFsrm1MzAkJ3SgQyhupgErJADP9WM8WbHPDVwQNV2c9C+YX68LreVpCc2iYTjXB38sSHrosievxAMqbX3ipjuQM+iiZjHlMI9lacsKK8UNLuMEEk51pOayJMrlllEVnM9OTq4EEEXMQj4kVbu3qgF7i2gab6pdGPFE= 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=SQHHcViV; arc=none smtp.client-ip=209.85.214.200 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="SQHHcViV" Received: by mail-pl1-f200.google.com with SMTP id d9443c01a7336-2cfa55c9430so29636705ad.0 for ; Mon, 03 Aug 2026 06:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1785764457; x=1786369257; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:references:mime-version:in-reply-to:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=Pw/rx9SP+mM7O539KcUF3r0TBZVycpjXm5LE9RCSGg0=; b=SQHHcViVFidPeEvFTLn9e2ao2Kgn31ShLAVrbsX6s5qcXRhmh8o/VYyqQ9DdK5Bi/9 ItDmbqzpnx1M/3gF+kQAucobAX5PdacfyT0d/jd4g2DQrgYZOuPIdidVKBCXl27I3qnb B/jlyfG1n/WqvBIOJzlrwz02lAZKG/EI6EcMnS7NmrRKbkYtFhkUTWLWDnKh+wTKmPPE fUAiMUf0btWjSTJB8fPknlerA3ri7ftQCdY8gcn+JQl529ll/GHFZk8insfZ4PzWQBFk nLdPdwvGrFyL1fjuKGiuwdK+T2DM+LlbJ53bYRKnMG7YdqP9p/L77IuCfun+oOR7jMKR /P1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785764457; x=1786369257; h=content-transfer-encoding:content-type: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 :content-type; bh=Pw/rx9SP+mM7O539KcUF3r0TBZVycpjXm5LE9RCSGg0=; b=YP9l+oHuJqDhCMoFi/xp+bx8A/KIi0oSwEDmq0+YTgNczklm34XzlpUcqMZzQ0hVG5 WaqFBh4dOZ0/fPRoBRp3Dk1gQx866byCUCdZLacPML/4DpunONVbL6CyFVb0dLCvVX/A mjVOfq977VU97+pLb32mNjxcm+yDItDOZxwUJimtY0kpdm+6Hjl795wNtQ0LHbboeYd6 RnLZMtgl85fSX+2zP+IsvNMphEaLPMX9uxMru99koNgHfPNQH0bvBUV94YZG/G97vem9 2Rm/aknPpHKZLenJd0aAASRXJQaR1zDM+maGijdWx8RX5ddsdJxeZuCxynst8mVEht6G 0jsQ== X-Gm-Message-State: AOJu0YwUB5rWu2onUoGfuMvmSzEkDB2+o5u3XpAZ1wQjePrr7GMLgPBw 74kO1X7SBWKwTMbbxqVh/otZ9BxflVJBbfVScQUqqPO9hBF1wkmp4itOqEnH5Qls9pR1UJCk7p7 zDXIjwQ== X-Received: from plsd7.prod.google.com ([2002:a17:902:b707:b0:2cf:ee73:1d9d]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:ebc3:b0:2ca:2079:91cc with SMTP id d9443c01a7336-2d052188c55mr109393695ad.5.1785764456738; Mon, 03 Aug 2026 06:40:56 -0700 (PDT) Date: Mon, 3 Aug 2026 06:40:53 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260731175834.1121005-1-pbonzini@redhat.com> Message-ID: Subject: Re: [PATCH] kvm: apply VM_READ/VM_WRITE checks to all VMA types From: Sean Christopherson To: Paolo Bonzini Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 03, 2026, Paolo Bonzini wrote: > On Fri, Jul 31, 2026 at 8:46=E2=80=AFPM Sean Christopherson wrote: > > > * if the PTE is present, follow_pfnmap_start() sets args.writable to > > > false and KVM_PFN_ERR_RO_FAULT is returned; > > > > > > * if no PTE is present, fixup_user_fault(FAULT_FLAG_WRITE) returns > > > -EFAULT after checking vma_permits_fault(), and hva_to_pfn() ends > > > up returning KVM_PFN_ERR_FAULT. > > > > > > With this patch KVM_PFN_ERR_RO_FAULT is returned uniformly. > > > > IMO, returning KVM_PFN_ERR_RO_FAULT on a read-only VMA is wrong. AFAIC= T, that > > behavior for VM_{IO,PFNMAP} was added by commit bd2fae8da794 ("KVM: do = not assume > > PTE is writable after follow_pfn"). Given that that's the only case wh= ere KVM > > returns KVM_PFN_ERR_RO_FAULT, I would much prefer to fix that wart and = cross our > > fingers nothing has come to rely on the behavior in the last ~5 years. >=20 > We can try, but I'd rather not do that in stable releases (while this > patch would be applied there, as a first step towards fixing the DRM > issue that Sergio reported=20 I don't see how this would help with fixup_user_fault() not actually fixing= a fault. Neither returning -EFAULT nor emulating is correct KVM behavior. > - it avoids the sashiko issue reported for > https://lore.kernel.org/r/20260731160514.1101989-1-pbonzini%40redhat.com/= ). But the issue Sashiko reported is just saying that KVM sometimes does what = I'm saying KVM should do all the time: return -EFAULT. Or did I misunderstand = that one too? :-) > > > For regular mappings a PROT_READ VMA, if placed in a writable memslot= , > > > would return KVM_PFN_ERR_FAULT instead of KVM_PFN_ERR_RO_FAULT when > > > the guest writes to it. This would cause a -EFAULT exit to userspace= , > > > instead of triggering emulation as the VM_IO|VM_PFNMAP arm would do; > > > > No, arm64 is checking the memslot, not the VMA. > > > > hva =3D gfn_to_hva_memslot_prot(memslot, gfn, &writable); > > write_fault =3D kvm_is_write_fault(vcpu); > > if (kvm_is_error_hva(hva) || (write_fault && !writable)) { > > > > Or are you talking about different code? >=20 > I am talking about the "arm" of the if/else if/else. :) LOL, overthought that one a bit. > > > > /* > > * GUP failed. It could be an inaccessible mapping, a pfnmap o= ne, > > * or the page might be absent. > > */ > > if (vma =3D=3D NULL || unlikely(!(vma->vm_flags & VM_READ)) || > > ((kfp->flags & FOLL_WRITE) && unlikely(!(vma->vm_flags & VM= _WRITE)))) { > > pfn =3D KVM_PFN_ERR_FAULT; > > } else if (vma->vm_flags & (VM_IO | VM_PFNMAP)) { > > r =3D hva_to_pfn_remapped(vma, kfp, &pfn); > > if (r =3D=3D -EAGAIN) > > goto retry; > > if (r < 0) > > pfn =3D KVM_PFN_ERR_FAULT; > > } else { > > pfn =3D kfp->flags & FOLL_NOWAIT ? KVM_PFN_ERR_NEEDS_IO= : > > KVM_PFN_ERR_FAULT; > > } >=20 > Yes, but I'd do that only in 7.3.