From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (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 2A5FB3D47BD for ; Tue, 23 Jun 2026 11:46:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782215182; cv=none; b=T/6++pw35wfDM+dXYR9q5PND4TbV+6vSevC3wdSks21MQX4y20ecBG4q2S8AlQh6TZpObt3klzK3d8xGY9W0/wJeuUXIrvbFZsLw4YB6Ty979wUgbT0SEjtNxJg0f/UCdzqIEkq8Y6eLQSJUc2NCLgu8I/L17NgbluUxErl7VbY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782215182; c=relaxed/simple; bh=/j4i5uRM9CfDoimZAimFxAHLg+HtSls+D9mWuiA2GSY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: Content-Type:MIME-Version; b=Pxc7ToWFggQ3I/8ZfTaiXbLZc2s0a104nHmj5t3mYBxJ1fZ1dea7BwYpl2pYejUjWGMfCa40IjELwaCh+n4CkiEoDYqpMowBKHuCZ05+P8ewDW/JGtn6q8vNsub6WMcHEppjoSgtKT72R6m/QQtLD7rick7C5fVpy4S+WyQdQ8k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=algjO7LK; arc=none smtp.client-ip=209.85.128.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="algjO7LK" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-490cf322ed0so43576815e9.1 for ; Tue, 23 Jun 2026 04:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782215180; x=1782819980; darn=vger.kernel.org; h=mime-version:content-transfer-encoding:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=6+RzNiQK0pXiSgFzNYp0CdnQlJdQX5A5EGONITWSYq0=; b=algjO7LKcgPhVrrqqxqz1bJ7fWz8dFwLDCIupa46Oe0pLfokXYKfqVJcfc/cE7Ja8f 0mDAApCo58Zt+L2lOC5XElCqG5TA4DiN7Av5DSk1n4w94eMNzOhC8qY6jyZ8oOokJuCy mqnlnV3TdYM8QSVOQgROVUGDpEd51WrLJ/2JxkMuOeBJ+zgPb1V9J5dqQOVkelsCqZ8R d1O9z73U71E0Bdb2IWk7q2bxqOlmKfAY0gzHGxUkItX86wbsqMPC4ykyCd6CIPAY3+W7 qE1NoJLqB9hUrKjo8duWZUQ8BDTSlLw84qlRNKYNpJeQp8mNRIJ0evODjC0MXVJgLth4 lTZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782215180; x=1782819980; h=mime-version:content-transfer-encoding:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=6+RzNiQK0pXiSgFzNYp0CdnQlJdQX5A5EGONITWSYq0=; b=WVAUSmVr2ivjw9u0qTXVWo3tENAdBRfRxzmK7Lzy9b+GEuKps3DDA67fDD0Gd1ONm7 irpgGf2hcGocx0qVijP/gnHIBWs4Tr06k+VhpVzmXH4amyQa/hp8ikQ9r+UrCR59m83t ORuhlsHfLOOFMHfChZ47i3gAjjwXW4zZHZ+yRHEufcKw7cd7jLKFvgY/mAlyjAIg3CT2 4iveDs8C1SPo2Q4X3Ttp2NY2Jhf8IlDuWDW/2uMC2fs0pgJ/LGn+08Ij2OA7zAvlW3aY eiSeAr7JWNpSCTN4mwsaAqbLWctv7jTuwsD4J/6dO/YpGmU5PwGAbSkuV0g6r0js/Ang 1ktA== X-Forwarded-Encrypted: i=1; AFNElJ8lJm8wZnwm1JmtBFaHyQmHZpbo1u7nkJ7gwH0wPlwUssYcgP271JUPcCUEnpdeXcKrwtc1iPEYU53NzHQ=@vger.kernel.org X-Gm-Message-State: AOJu0YyrYu5X7bXsxPk8vLDT6kkFGmwEoRSwPcooUA2eDy34PJmWG9Jk wvAPuVhVSd9TR++Ps/vYJHrXrN6wQOZWJOAwlTjNUV54ZJXd/NXEs2oH X-Gm-Gg: AfdE7ckNN8iNlbkWndcgJCGvT9jfvbJ+qk9/ZJraZoI/V5a3jZOA9odGPTaz+58eX3Y b8IdSbMOme1oEH3RzSV3Dlsj/Wa8csF8awUSXzYpiVxswQCGox8O3PTnzyOasK6uR6AAWh3AM/s HGX++wyRSzoLZlrusS2W+cMQVvnJYB0SW2JGDUiepN7SgBZFhyYa3O6JotrNmVQ12Y0wCWiKUed um5S5CzR8/WDrAcWZEnP0q6kqUe0ZXuzzHh6rC8Skm5De0BhgYuZLLAQ5Ucx+JZ+G282QjdrKIn pFPjb8WTT9vHmVL6boayiK46EdVBb2AUYXUXQFKdfEWGfiI0HuXOF5sQYIBFYqSEMg1XHqpng78 e6mj140gO+Oe0ggwyUmE0IJeiF16Z5/a27kK+ngxSf20CvqFbWROXL+646CqoL9sfKV10vUW4H/ anjoPwi0eLZyOWEd6ajTZSupzGi85FExMTjgV6 X-Received: by 2002:a05:600c:68d3:b0:490:b724:5085 with SMTP id 5b1f17b1804b1-4925b3bbac7mr25901405e9.33.1782215179473; Tue, 23 Jun 2026 04:46:19 -0700 (PDT) Received: from build-server.lab.ber ([62.96.37.222]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4923fe7ba08sm370719855e9.11.2026.06.23.04.46.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jun 2026 04:46:18 -0700 (PDT) From: Mikhail Malyshev To: Sean Christopherson 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" Subject: Re: [PATCH 1/1] KVM: x86/mmu: Emulate, don't kill the VM, on access to a disabled passthrough BAR Date: Tue, 23 Jun 2026 11:46:18 +0000 Message-ID: <178221517808.3589966.15538835749975810737@gmail.com> In-Reply-To: References: <20260621133708.3454718-1-mike.malyshev@gmail.com> <20260621133708.3454718-2-mike.malyshev@gmail.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Mon, Jun 22, 2026, Sean Christopherson wrote: > 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. Agreed, thanks - that's the right layer, and the PROT_NONE case alone is reason enough not to overload the pfn classification the way I did. For context on v1's shape: localizing the fix in KVM was a deliberate scoping choice - it was the smallest change that stopped the crash without updating another major component (the VMM) at the same time. I agree that optimizing for a single-component change put the policy in the wrong layer; KVM reporting KVM_EXIT_MEMORY_FAULT and the VMM applying device semantics is the right split. Plan: implement your suggestion (kvm_mmu_prepare_memory_fault_exit() in kvm_handle_error_pfn()) and pair it with a QEMU change that recognizes a memory-fault on a vfio-pci BAR whose memory space is currently disabled and emulates it as an Unsupported Request (reads all ones, writes dropped) rather than aborting. Note QEMU's current KVM_EXIT_MEMORY_FAULT handling only covers guest_memfd shared/private conversion, so this is new vfio-pci handling on the VMM side - I'll test the kernel + QEMU pair against the reproducer before sending v2. FWIW this is the concrete user the 2024 KVM_CAP_MEMORY_FAULT_INFO work (Zr-8M9rYplgN6IS3) was missing: an assigned Intel iGPU whose guest driver clears PCI_COMMAND.MEM on one vCPU while another is mid-MMIO to the BAR, which kills the VM. Reproducible on demand and seen in the field. Two questions before I respin: - Prefer I revive Anish's x86 patch from that series (rebased), or a fresh minimal change against kvm-x86/next? The tree has moved a lot since 2024 (kvm_follow_pfn, etc.), so I was leaning fresh with a Link: to the original and Suggested-by: you. - You'd asked for KVM_BUG_ON() + -EIO conversions on that x86 patch - still want those folded in, and should this stay x86-only or also cover arm64? Thanks, Mike