From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH] kvm: apply VM_READ/VM_WRITE checks to all VMA types
Date: Mon, 3 Aug 2026 06:40:53 -0700 [thread overview]
Message-ID: <anCZoc65i2xXNQgO@google.com> (raw)
In-Reply-To: <CABgObfZ5sPgfJz-_reACs5WkjRRkdNuinfY+nSrdHvG5xSiKUA@mail.gmail.com>
On Mon, Aug 03, 2026, Paolo Bonzini wrote:
> On Fri, Jul 31, 2026 at 8:46 PM Sean Christopherson <seanjc@google.com> 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. AFAICT, 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 where 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.
>
> 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
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 = gfn_to_hva_memslot_prot(memslot, gfn, &writable);
> > write_fault = kvm_is_write_fault(vcpu);
> > if (kvm_is_error_hva(hva) || (write_fault && !writable)) {
> >
> > Or are you talking about different code?
>
> 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 one,
> > * or the page might be absent.
> > */
> > if (vma == NULL || unlikely(!(vma->vm_flags & VM_READ)) ||
> > ((kfp->flags & FOLL_WRITE) && unlikely(!(vma->vm_flags & VM_WRITE)))) {
> > pfn = KVM_PFN_ERR_FAULT;
> > } else if (vma->vm_flags & (VM_IO | VM_PFNMAP)) {
> > r = hva_to_pfn_remapped(vma, kfp, &pfn);
> > if (r == -EAGAIN)
> > goto retry;
> > if (r < 0)
> > pfn = KVM_PFN_ERR_FAULT;
> > } else {
> > pfn = kfp->flags & FOLL_NOWAIT ? KVM_PFN_ERR_NEEDS_IO :
> > KVM_PFN_ERR_FAULT;
> > }
>
> Yes, but I'd do that only in 7.3.
next prev parent reply other threads:[~2026-08-03 13:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 17:58 [PATCH] kvm: apply VM_READ/VM_WRITE checks to all VMA types Paolo Bonzini
2026-07-31 18:46 ` Sean Christopherson
2026-08-03 5:54 ` Paolo Bonzini
2026-08-03 13:40 ` Sean Christopherson [this message]
2026-08-03 17:17 ` Paolo Bonzini
2026-08-03 22:40 ` Sean Christopherson
2026-08-04 7:43 ` Paolo Bonzini
2026-08-04 13:11 ` Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=anCZoc65i2xXNQgO@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.