From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 25E7CC7EE29 for ; Thu, 8 Jun 2023 14:31:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235844AbjFHObW (ORCPT ); Thu, 8 Jun 2023 10:31:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60942 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233268AbjFHObU (ORCPT ); Thu, 8 Jun 2023 10:31:20 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8A2532D4B; Thu, 8 Jun 2023 07:31:19 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 18CD3615EB; Thu, 8 Jun 2023 14:31:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7865AC4339B; Thu, 8 Jun 2023 14:31:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686234678; bh=smOlSFURXV/s7EAF5y4OlxqQHukXeLLHVSrQ6ekRJwg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=qH0ODOPGEoCaddyIvlPe8Azx4s6sNmANXyu/wSV0GCSPxt86KtqCizB18Ds/KCKE0 kxmFyOWKXjx8QpmjSSAxyFUTEM0ng5dwCokPzS6oXoE+zkV/hinxAxfE8G266QEigj rW4I/KxLbIjzxSg2Al9zyTpehg6gYGPsga1maVikITQm+n59a+5BEcpQ1wCASady5H AkR6Xuozk178xSIvWCzOPFRnH56YluPWll0UrNH6RuabEcnL9LK4BdFHMXpV2/uFKK x+9gl0kMnV7j6Y4IX72seNDO4JogJP/Sm7TMvpiZOkC4SUxq+UimopGm6gGwnc7t/R WiwHKd1OvE0/A== Received: from 152.5.30.93.rev.sfr.net ([93.30.5.152] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1q7GfT-003oxI-Vl; Thu, 08 Jun 2023 15:31:16 +0100 Date: Thu, 08 Jun 2023 15:31:09 +0100 Message-ID: <87bkhqnhzm.wl-maz@kernel.org> From: Marc Zyngier To: Gavin Shan Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, pbonzini@redhat.com, seanjc@google.com, oliver.upton@linux.dev, hshuai@redhat.com, zhenyzha@redhat.com, shan.gavin@gmail.com Subject: Re: [PATCH] KVM: Avoid illegal stage2 mapping on invalid memory slot In-Reply-To: <20230608090348.414990-1-gshan@redhat.com> References: <20230608090348.414990-1-gshan@redhat.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 93.30.5.152 X-SA-Exim-Rcpt-To: gshan@redhat.com, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, pbonzini@redhat.com, seanjc@google.com, oliver.upton@linux.dev, hshuai@redhat.com, zhenyzha@redhat.com, shan.gavin@gmail.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Hi Gavin, On Thu, 08 Jun 2023 10:03:48 +0100, Gavin Shan wrote: > > We run into guest hang in edk2 firmware when KSM is kept as running > on the host. The edk2 firmware is waiting for status 0x80 from QEMU's > pflash device (TYPE_PFLASH_CFI01) during the operation for sector > erasing or buffered write. The status is returned by reading the > memory region of the pflash device and the read request should > have been forwarded to QEMU and emulated by it. Unfortunately, the > read request is covered by an illegal stage2 mapping when the guest > hang issue occurs. The read request is completed with QEMU bypassed and > wrong status is fetched. > > The illegal stage2 mapping is populated due to same page mering by > KSM at (C) even the associated memory slot has been marked as invalid > at (B). > > CPU-A CPU-B > ----- ----- > ioctl(kvm_fd, KVM_SET_USER_MEMORY_REGION) > kvm_vm_ioctl_set_memory_region > kvm_set_memory_region > __kvm_set_memory_region > kvm_set_memslot(kvm, old, NULL, KVM_MR_DELETE) > kvm_invalidate_memslot > kvm_copy_memslot > kvm_replace_memslot > kvm_swap_active_memslots (A) > kvm_arch_flush_shadow_memslot (B) > same page merging by KSM > kvm_mmu_notifier_change_pte > kvm_handle_hva_range > __kvm_handle_hva_range (C) > > Fix the issue by skipping the invalid memory slot at (C) to avoid the > illegal stage2 mapping. Without the illegal stage2 mapping, the read > request for the pflash's status is forwarded to QEMU and emulated by > it. The correct pflash's status can be returned from QEMU to break > the infinite wait in edk2 firmware. Huh, nice one :-(. > > Cc: stable@vger.kernel.org # v5.13+ > Fixes: 3039bcc74498 ("KVM: Move x86's MMU notifier memslot walkers to generic code") > Reported-by: Shuai Hu > Reported-by: Zhenyu Zhang > Signed-off-by: Gavin Shan > --- > virt/kvm/kvm_main.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > index 479802a892d4..7f81a3a209b6 100644 > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -598,6 +598,9 @@ static __always_inline int __kvm_handle_hva_range(struct kvm *kvm, > unsigned long hva_start, hva_end; > > slot = container_of(node, struct kvm_memory_slot, hva_node[slots->node_idx]); > + if (slot->flags & KVM_MEMSLOT_INVALID) > + continue; > + > hva_start = max(range->start, slot->userspace_addr); > hva_end = min(range->end, slot->userspace_addr + > (slot->npages << PAGE_SHIFT)); I don't immediately see what makes it safer. If we're not holding one of slots_{,arch_}lock in the notifier, we can still race against the update, can't we? I don't think holding the srcu lock helps us here. Thanks, M. -- Without deviation from the norm, progress is not possible.