From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.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 DFE3C352002 for ; Mon, 22 Jun 2026 23:23:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782170629; cv=none; b=WqwpPrQwR7ut4avoWxIBcnT2mKmk8UqAJt/bI9/x0MtYV4/qLUQ2/Fdgjdwoy+zoDGQwx6jp/zSRs9yNeJix0ceg9H/yzasp1Qda7QvMr/DD2cIYL/gO26QYQ5NFaYWGR9RQ+DClm8IJXP/iuUGzZLd12Hn1wMu9tTerGYJlsVw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782170629; c=relaxed/simple; bh=iT76L4fVr9ilJU9xRM8ws1sAqll6cvyzaUE7RZDtkJI=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=b7OAD5P//TERh6JmRKywaps3uPyoB5DdHq0EunepdS5p87WLxleXgWjuWKkzTckCKkExYs/r2IXdf40KrT+kNhvM/RSYgqMnRLc7sPCOgSN0yPnpQY3JPHG2FpzpkUoX22qBS0GD9ZOtuqfXVUDZgCq3Tgx/WcTUu0w7zVZ/qOA= 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=rwg9UTgA; arc=none smtp.client-ip=209.85.214.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="rwg9UTgA" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2c354050c34so40928845ad.3 for ; Mon, 22 Jun 2026 16:23:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1782170627; x=1782775427; 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=1l368LEMViqYsAYRY3CcxbJd6IIQZRI4794Ia7jsAaQ=; b=rwg9UTgAjiLIC2oHa24cU4iyDCJ9lrnkotKyNmL7O5co46Xd4k8NdUKak4tqWshpj2 udMLpmUgTQQcRCAs+cPS3lvG3gArVLSZcS5nr9t9entKUJlhHTUgJgIqObmzxFglBk+l mcN+lM4nIeeTfXRr00n0TkM3JW3iYAd2fCBwJMDSf+A21+nQgcNWGrhQ/4++iaoK5SkF KB2Onx7BiK3y9M1VJsRIVp+Ip3GHalcqtAx5IH0JwQ8kZfPdloRA40rhrOM3MH+u+gXe e6tUdAehgZRJy24W5Rn0Da1HuOQlmyemta+fbe8Se4Qz1OKpKFQj7xU65pp7MDu3RgDT H31g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782170627; x=1782775427; 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=1l368LEMViqYsAYRY3CcxbJd6IIQZRI4794Ia7jsAaQ=; b=XUtmW/vuhMBnHd4L5lj3uvABizvnRR3CsylhFRfaNY6+702IIT7XaxwJtxYFazK/m7 /MDKAf+1knFAxdAbqvXWn/YaGnzq0+nIeOubI/Zn/RTxmDdsCI7rlpV5jBJGDoU3D28e mgOMN63YLyZ4qDqZ05N8Q1LopapOOeG/qg26JeUFWItbrp1L9vhWN9eSAlTYYC3vmJMP ZGDsBdkZJTSqcymSSgoJoVMeW/y4ksETqgCe34DyoH4J1dLx0Po9o9iifmahTlsNJNaJ HiImU7o6ddHxQoJicIlUwnZfjTs9+zb+gBh0BKgkMLFWdSQ2eApupOmLpAWqluw11wlZ u5LQ== X-Forwarded-Encrypted: i=1; AHgh+RrbXVXbjSamTWt1tZtKqcSeIwBQZ3SoSUQDR0hESeEqE1y+lKAvZshMu9fATZ2L6S+gJrILfiNFxLooEPo=@vger.kernel.org X-Gm-Message-State: AOJu0Yy+N72gF/M76xFc2yj/S9mCuld6fnIYs8L/+UG8Jqtg7fLeAoJE lbfEP0BKrM1BgEiSslKF1Agqb/rl0sEDrNLGfrrLVgcI6h0etecnuu5ldw8fxSB+RtWUat6xfPD chLoPag== X-Received: from plom12.prod.google.com ([2002:a17:903:3c0c:b0:2bf:1486:2669]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:f691:b0:2c6:a172:55a6 with SMTP id d9443c01a7336-2c718f4ffa7mr171684595ad.9.1782170626901; Mon, 22 Jun 2026 16:23:46 -0700 (PDT) Date: Mon, 22 Jun 2026 16:23:46 -0700 In-Reply-To: <20260621133708.3454718-2-mike.malyshev@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260621133708.3454718-1-mike.malyshev@gmail.com> <20260621133708.3454718-2-mike.malyshev@gmail.com> Message-ID: Subject: Re: [PATCH 1/1] KVM: x86/mmu: Emulate, don't kill the VM, on access to a disabled passthrough BAR From: Sean Christopherson To: mike.malyshev@gmail.com Cc: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, "H. Peter Anvin" Content-Type: text/plain; charset="us-ascii" On Sun, Jun 21, 2026, mike.malyshev@gmail.com wrote: > --- > arch/x86/kvm/mmu/mmu.c | 16 +++++++++++++++- > include/linux/kvm_host.h | 8 ++++++++ > virt/kvm/kvm_main.c | 9 ++++++++- > 3 files changed, 31 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > index 91843e9224d04..115e2c4db5fa0 100644 > --- a/arch/x86/kvm/mmu/mmu.c > +++ b/arch/x86/kvm/mmu/mmu.c > @@ -4759,8 +4759,22 @@ static int kvm_mmu_faultin_pfn(struct kvm_vcpu *vcpu, > if (ret != RET_PF_CONTINUE) > return ret; > > - if (unlikely(is_error_pfn(fault->pfn))) > + if (unlikely(is_error_pfn(fault->pfn))) { > + /* > + * A passed-through PCI BAR is backed by a VM_IO/VM_PFNMAP > + * mapping whose fault handler refuses to install a PTE while the > + * device's memory space is disabled (e.g. the guest cleared > + * PCI_COMMAND.MEM). The fault then fails even though the memslot > + * is still valid. Treat such an access as MMIO and emulate it so > + * the guest observes Unsupported Request semantics, matching > + * bare metal, instead of killing the VM with -EFAULT. Genuine, > + * non-pfnmap errors still take the fatal path. > + */ > + if (fault->pfn == KVM_PFN_ERR_PFNMAP) > + return kvm_handle_noslot_fault(vcpu, fault, access); I really don't like this. It's an ABI change that affects years of precedent, and the ABI it creates is very haphazard. E.g. why should PFNMAP memory get emulate MMIO semantics for this case? And a PROT_NONE VMA really shouldn't get MMIO semantics either. I would rather have KVM exit to userspace with KVM_EXIT_MEMORY_FAULT and fill run->memory_fault, i.e. diff --git arch/x86/kvm/mmu/mmu.c arch/x86/kvm/mmu/mmu.c index 26ed97efda91..aff6b82b0fdd 100644 --- arch/x86/kvm/mmu/mmu.c +++ arch/x86/kvm/mmu/mmu.c @@ -3534,6 +3534,7 @@ static int kvm_handle_error_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fa return RET_PF_RETRY; } + kvm_mmu_prepare_memory_fault_exit(vcpu, fault); return -EFAULT; } Huh, knew I had a feeling of deja vu. I even proposed this as a fix a while back. I don't know why it didn't go anywhere. Maybe simply because no one cared at the time? https://lore.kernel.org/all/Zr-8M9rYplgN6IS3@google.com