Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp1849448pxy; Thu, 6 May 2021 18:06:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzjQJlkfNEXloCFM6DxDc++ixLbkTwuh2VBQRS1S9Eo70KKwEeusVoCA85K//XxknlQoTTR X-Received: by 2002:a62:6544:0:b029:261:14cc:b11d with SMTP id z65-20020a6265440000b029026114ccb11dmr7512423pfb.12.1620349610468; Thu, 06 May 2021 18:06:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620349610; cv=none; d=google.com; s=arc-20160816; b=cZsVJFRLPLF3Dlqi+n4+r+vU6AFbgDEOlsRPvJmUANphe0UJ0GGsdmLYrFxJ9ltT11 6b5Udg7zx6J8x/SDtKHwdJdH7MVabQGpimhg870gx7afgzlDxMGCCjEaXPb4AYOnvPzE 3cMh/MD8UcD1RKNCN7yg/LY9VTPrLjThC26tF95cqZl1LhHIbh1PuW5H3EHVY6NUVH9w ZLTyRhiYn8yWedXl8EmqK5PpDbMmQRwZpbkegxAIQ//H2Ubxnee/BXc72U284cx776I3 Iq69S18oPXgBooxIN3WvsknTJNhCDuqbu0kvKyZK/Rjj8kdl0b8IcPkDsQK9bU/P2f04 Op0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=hNnmB2N+G/xliEHvFgXD/jk8b5W6LQ1nCJcVUsPji2I=; b=LCJljjNGH8VqBK3okZBJtTrtmPOEs2IDCSWEENHEfqAiAIdlaBC55rYFrEix3rOmKT YIkBdwJ/Du7iVplc49dmLdW0fKqfJqF9e/sXO0O5LMa7f46IO0eK4s87QSpXub95pG90 Mo+nEJ84Gb2n6LcvThHHOjTw9x6xn67S+vp+Q2yZPVcaFewZyKjhb5XmDshtk1lyy34k wQNJ3udkNgK7yyjuSoBu02udz/mNJcm2rzYxpdMPPVuZryejEZcXLbE+2QkZ5u9o8eAo 1nq8VRxT1ZEiuknoTu1Wp3uMjnXJcXx9X+bpI0MWe4kyLUHzcDjlsw+7dMez6HHn7hFk kovg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=cXuAAA48; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k12si4929255plt.7.2021.05.06.18.06.36; Thu, 06 May 2021 18:06:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=cXuAAA48; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231906AbhEFX2d (ORCPT + 99 others); Thu, 6 May 2021 19:28:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54620 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231733AbhEFX2c (ORCPT ); Thu, 6 May 2021 19:28:32 -0400 Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 00C31C061761 for ; Thu, 6 May 2021 16:27:32 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id c21so5853636pgg.3 for ; Thu, 06 May 2021 16:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=hNnmB2N+G/xliEHvFgXD/jk8b5W6LQ1nCJcVUsPji2I=; b=cXuAAA48mu88DAuWJxtAPWw5wM0J3HL3GxZE9djShlADFL8vJ3ysETvXY6SV/jQdeQ NHXdnwBUs5Zij7g0Y4e80hmMJi4XbWulwDIXgHeb5lyNB8B8Yzyo4X4KkZOz60OTnIfg SQVUoOaco97WIizqiL/OwN2ey5smZPwKzpsENT/Wi7GA/4wzFT0SDo1rYJIBDlsjjySK ky8BdcIpcc4BjXuYD1OS9Fckz0v81qKM6y4k1JrlD9dCCs6l4UhY8JrkQ0xHEqUDECTI InG95rF0j8N87Xez49u3CR2+ZF1F28laFfCbm273k7ymbrKIkNY7SaY/CHGIITjm1UC5 tZFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=hNnmB2N+G/xliEHvFgXD/jk8b5W6LQ1nCJcVUsPji2I=; b=gMvIHEM3Tp66ziQSOwkoi9hCstHkPr9RckLGli0E1G+nYtkEPuwMmk+AiT49nGrCHA N3VymgW9IO6I7DXxuGSTtf6eBkLwd6jMep9jckBf8pUJupKlrzgaLybYKG5ppc43VvtQ gondXC7N3Iwj2TsBUdQWKrw+Nm+xF6ZZFaGkN0CU1JkR0IuMGa40wY8LnTsYHIa2BVBw MF26y5x1fqZ9lMT/JOJvuo+9bwL0SYwPK0Hxubbjx5RgZe63PsRDYly7Xsyi22GRodGv mjwrxnffL6CtDtCn5f5wdRzCE6EhChGwLk0rMQ55xpgZFTV8dzChR8e9OYBlF9POLkZn Dkog== X-Gm-Message-State: AOAM532IiPU+h6TUfZ60UT0beDhpsLLcKuwFsoEV3f+EO/Ll3DQ/RS7l brWU4cFDEpYcc+6ifzfdWrM6ew== X-Received: by 2002:a63:6986:: with SMTP id e128mr6751721pgc.16.1620343651335; Thu, 06 May 2021 16:27:31 -0700 (PDT) Received: from google.com (240.111.247.35.bc.googleusercontent.com. [35.247.111.240]) by smtp.gmail.com with ESMTPSA id c6sm10411626pjs.11.2021.05.06.16.27.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 May 2021 16:27:30 -0700 (PDT) Date: Thu, 6 May 2021 23:27:27 +0000 From: Sean Christopherson To: Jim Mattson Cc: KarimAllah Ahmed , the arch/x86 maintainers , kvm list , LKML , Paolo Bonzini Subject: Re: [PATCH v6 08/14] KVM/nVMX: Use kvm_vcpu_map when mapping the posted interrupt descriptor table Message-ID: References: <1548966284-28642-1-git-send-email-karahmed@amazon.de> <1548966284-28642-9-git-send-email-karahmed@amazon.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 06, 2021, Jim Mattson wrote: > On Thu, Jan 31, 2019 at 12:28 PM KarimAllah Ahmed wrote: > > > > Use kvm_vcpu_map when mapping the posted interrupt descriptor table since > > using kvm_vcpu_gpa_to_page() and kmap() will only work for guest memory > > that has a "struct page". > > > > One additional semantic change is that the virtual host mapping lifecycle > > has changed a bit. It now has the same lifetime of the pinning of the > > interrupt descriptor table page on the host side. > > > > Signed-off-by: KarimAllah Ahmed > > Reviewed-by: Konrad Rzeszutek Wilk > > --- > > v4 -> v5: > > - unmap with dirty flag > > > > v1 -> v2: > > - Do not change the lifecycle of the mapping (pbonzini) > > --- > > arch/x86/kvm/vmx/nested.c | 43 ++++++++++++------------------------------- > > arch/x86/kvm/vmx/vmx.h | 2 +- > > 2 files changed, 13 insertions(+), 32 deletions(-) > > > > diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c > > index 31b352c..53b1063 100644 > > --- a/arch/x86/kvm/vmx/nested.c > > +++ b/arch/x86/kvm/vmx/nested.c > > @@ -230,12 +230,8 @@ static void free_nested(struct kvm_vcpu *vcpu) > > vmx->nested.apic_access_page = NULL; > > } > > kvm_vcpu_unmap(vcpu, &vmx->nested.virtual_apic_map, true); > > - if (vmx->nested.pi_desc_page) { > > - kunmap(vmx->nested.pi_desc_page); > > - kvm_release_page_dirty(vmx->nested.pi_desc_page); > > - vmx->nested.pi_desc_page = NULL; > > - vmx->nested.pi_desc = NULL; > > - } > > + kvm_vcpu_unmap(vcpu, &vmx->nested.pi_desc_map, true); > > + vmx->nested.pi_desc = NULL; > > > > kvm_mmu_free_roots(vcpu, &vcpu->arch.guest_mmu, KVM_MMU_ROOTS_ALL); > > > > @@ -2868,26 +2864,15 @@ static void nested_get_vmcs12_pages(struct kvm_vcpu *vcpu) > > } > > > > if (nested_cpu_has_posted_intr(vmcs12)) { > > - if (vmx->nested.pi_desc_page) { /* shouldn't happen */ > > - kunmap(vmx->nested.pi_desc_page); > > - kvm_release_page_dirty(vmx->nested.pi_desc_page); > > - vmx->nested.pi_desc_page = NULL; > > - vmx->nested.pi_desc = NULL; > > - vmcs_write64(POSTED_INTR_DESC_ADDR, -1ull); > > + map = &vmx->nested.pi_desc_map; > > + > > + if (!kvm_vcpu_map(vcpu, gpa_to_gfn(vmcs12->posted_intr_desc_addr), map)) { > > + vmx->nested.pi_desc = > > + (struct pi_desc *)(((void *)map->hva) + > > + offset_in_page(vmcs12->posted_intr_desc_addr)); > > + vmcs_write64(POSTED_INTR_DESC_ADDR, > > + pfn_to_hpa(map->pfn) + offset_in_page(vmcs12->posted_intr_desc_addr)); > > } > > Previously, if there was no backing page for the > vmcs12->posted_intr_desc_addr, we wrote an illegal value (-1ull) into > the vmcs02 POSTED_INTR_DESC_ADDR field to force VM-entry failure. The "vmcs_write64(POSTED_INTR_DESC_ADDR, -1ull)" above is for the "impossible" case where the PI descriptor was already mapped. The error handling for failure to map is below. The (forced) VM-Exit unmap paths don't stuff vmcs02 either. In other words, I think the bug was pre-existing. > Now, AFAICT, we leave that field unmodified. For a newly constructed vmcs02, > doesn't that mean we're going to treat physical address 0 as the address of > the vmcs02 posted interrupt descriptor? PA=0 is the happy path. Thanks to L1TF, that memory is always unused. If mapping for a previous VM-Enter succeeded, vmcs02.POSTED_INTR_DESC_ADDR will hold whatever PA was used for the last VM-Enter. > > - page = kvm_vcpu_gpa_to_page(vcpu, vmcs12->posted_intr_desc_addr); > > - if (is_error_page(page)) > > - return; Error path for failure to map. > > - vmx->nested.pi_desc_page = page; > > - vmx->nested.pi_desc = kmap(vmx->nested.pi_desc_page); > > - vmx->nested.pi_desc = > > - (struct pi_desc *)((void *)vmx->nested.pi_desc + > > - (unsigned long)(vmcs12->posted_intr_desc_addr & > > - (PAGE_SIZE - 1))); > > - vmcs_write64(POSTED_INTR_DESC_ADDR, > > - page_to_phys(vmx->nested.pi_desc_page) + > > - (unsigned long)(vmcs12->posted_intr_desc_addr & > > - (PAGE_SIZE - 1))); > > } > > if (nested_vmx_prepare_msr_bitmap(vcpu, vmcs12)) > > vmcs_set_bits(CPU_BASED_VM_EXEC_CONTROL, > > @@ -3911,12 +3896,8 @@ void nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32 exit_reason, > > vmx->nested.apic_access_page = NULL; > > } > > kvm_vcpu_unmap(vcpu, &vmx->nested.virtual_apic_map, true); > > - if (vmx->nested.pi_desc_page) { > > - kunmap(vmx->nested.pi_desc_page); > > - kvm_release_page_dirty(vmx->nested.pi_desc_page); > > - vmx->nested.pi_desc_page = NULL; > > - vmx->nested.pi_desc = NULL; > > - } > > + kvm_vcpu_unmap(vcpu, &vmx->nested.pi_desc_map, true); > > + vmx->nested.pi_desc = NULL; > > > > /* > > * We are now running in L2, mmu_notifier will force to reload the > > diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h > > index f618f52..bd04725 100644 > > --- a/arch/x86/kvm/vmx/vmx.h > > +++ b/arch/x86/kvm/vmx/vmx.h > > @@ -143,7 +143,7 @@ struct nested_vmx { > > */ > > struct page *apic_access_page; > > struct kvm_host_map virtual_apic_map; > > - struct page *pi_desc_page; > > + struct kvm_host_map pi_desc_map; > > > > struct kvm_host_map msr_bitmap_map; > > > > -- > > 2.7.4 > >