Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp530229rwl; Tue, 11 Apr 2023 23:47:49 -0700 (PDT) X-Google-Smtp-Source: AKy350ZLyLYcP9lk+hp+A8kG6dbQsIL5dyAmc6UHmjPCnhDy1UReNCnjl3TMshjw0AAEHUFnWRfX X-Received: by 2002:a17:907:6d86:b0:94a:a77b:363a with SMTP id sb6-20020a1709076d8600b0094aa77b363amr8725584ejc.3.1681282069473; Tue, 11 Apr 2023 23:47:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681282069; cv=none; d=google.com; s=arc-20160816; b=yp/LGqVcBxrwZN6t1x5/7v/IfIufgA4blTt10DShOESwU7YjEfgKNnt2936N+WGbla zBB5PPZcftuNX5mQmELe4WsjP/YeTNohHb9ooejajQznwcPBVaKhvf7TMQ2Zu6j2sjwH UpqOiH27/ku6UXENZPoa46usrfLejQqu0BCfw3c6ZZnbvS7UVfWBtZBoOL1kyRBIRClP I2Y4WafwgplJTi2Tf115+c0lgLmiYUKto/a8pyvc941u8DF0YukZ89mFFVIUvx8wTRlR 1tF8P18b+vQjUdo6wpG1EG490rcHvFlie9phmfL2EqEWY3i4ebvQIK1o4SO+pFtXeZH9 Bl6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=iYkU2h5uuqeCAix2xVoQ4YssyuBrvdvQQLmL8KGrxsM=; b=HItkNIUMUxCksHKsY+ksGaJcsm/Uw6R9mEJHErPU4vVXs8Kn3YBXE2Ou2SXxHpVnrU cU2+Tt5tvU5dPwdRpgHx+2w38pxrXUiGQh+/wjPLRuy+QNlJw/CwVa0gU0mJLNNn6XGm aV2rUfpsWE4rfcJufM/wSIU9esPrlNHvYKZNrStS49NcvDEz2vs3RAdVvUCHxIlpIvbt DqaceCddQhn6pQCFmxqO6+6bpttxHRrIQKLWND10jOl7pylevQwf/PAJeHb4e3PYqwpF mEHSjGbtnse0lHpkG6GY0DsIW4BCNXzK3rAZN/w02P7OlrEEtwfkjixcq2/n2NadpTlv csWQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=UUCwMGad; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gz20-20020a170906f2d400b0094a9b6570d5si5238006ejb.88.2023.04.11.23.47.25; Tue, 11 Apr 2023 23:47:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=UUCwMGad; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229656AbjDLGdN (ORCPT + 99 others); Wed, 12 Apr 2023 02:33:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48078 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229515AbjDLGdM (ORCPT ); Wed, 12 Apr 2023 02:33:12 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 45ECE59FA for ; Tue, 11 Apr 2023 23:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1681281140; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iYkU2h5uuqeCAix2xVoQ4YssyuBrvdvQQLmL8KGrxsM=; b=UUCwMGadrki5JWKlGDd5YjsjNgtVCTlnEpCZt6j+HLOJjofGhPeyd2f4mk6t3iGow0CjMe ctdATfOLqFNk3wIFeRSF2Amgv5hpoMJsQx+LQ8Renv/oCF00vf8nWjF5RAtZpg/1fhBbrQ qKxHSLFai7Q4MAeJVMnbPDj+25CDEJY= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-437-9vvyyCxoNmikpa99EVdNig-1; Wed, 12 Apr 2023 02:32:19 -0400 X-MC-Unique: 9vvyyCxoNmikpa99EVdNig-1 Received: by mail-wr1-f70.google.com with SMTP id v20-20020adfa1d4000000b002f3dee3d83dso422646wrv.16 for ; Tue, 11 Apr 2023 23:32:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681281137; x=1683873137; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=iYkU2h5uuqeCAix2xVoQ4YssyuBrvdvQQLmL8KGrxsM=; b=7abKxGcYGJK8lG1NZurgyNzyGORwu1TaoE05dG65le5W03Ed5vTcGh/2DLY6zgyhUU YqOgjm2UprCNFdzcAZyc1P1GYWIwzd6uNb+5NZqDPNOR/zgwnop90XDhmUk7qqCzmWYG ssnIKJ4qSUWgje+p57tCzL9Et9qwSjhKzuLKsTSJHpkcobV0UR7i+mP/KjLemIWYp8Uh EaJgmsPNuLYhNFicDRpjXuiwpDkmKExupkxTQC0OvSTdz3TDwxQ/Z6zpJsfrJYEif+e0 TfZyidxOd2BoRFkxb4d1q+S/p0UiasIN0d7aL3J11Kc7E2jmXn9m1D9zl97OO3ny3LFz wNWA== X-Gm-Message-State: AAQBX9cr1qFOHu2bvh6OVKfwQC54UnEDu6pQy/BMtg4ZcsPrWaYPfK1C JeJwxHEfM+58cvyiR70OYJs56c0+rxzKjoYtlVPmWgmQ96ZQLiIIVkoVs7WVaHiQn7xg1sVdhff 1FX1KsAqsOMeHQfLJPw17wpi+WFm1tYunZEbwxBlJS0dDNw9b89Y2bQ== X-Received: by 2002:a5d:4f0e:0:b0:2ef:b5e1:f6f9 with SMTP id c14-20020a5d4f0e000000b002efb5e1f6f9mr1138577wru.8.1681281137429; Tue, 11 Apr 2023 23:32:17 -0700 (PDT) X-Received: by 2002:a5d:4f0e:0:b0:2ef:b5e1:f6f9 with SMTP id c14-20020a5d4f0e000000b002efb5e1f6f9mr1138568wru.8.1681281137152; Tue, 11 Apr 2023 23:32:17 -0700 (PDT) MIME-Version: 1.0 References: <20230410150130.837691-1-lulu@redhat.com> In-Reply-To: From: Cindy Lu Date: Wed, 12 Apr 2023 14:31:38 +0800 Message-ID: Subject: Re: [PATCH] vhost_vdpa: fix unmap process in no-batch mode To: Jason Wang Cc: mst@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, netdev@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 11, 2023 at 5:14=E2=80=AFPM Jason Wang wr= ote: > > On Tue, Apr 11, 2023 at 3:29=E2=80=AFPM Cindy Lu wrote: > > > > On Tue, Apr 11, 2023 at 11:10=E2=80=AFAM Jason Wang wrote: > > > > > > On Mon, Apr 10, 2023 at 11:01=E2=80=AFPM Cindy Lu w= rote: > > > > > > > > While using the no-batch mode, the process will not begin with > > > > VHOST_IOTLB_BATCH_BEGIN, so we need to add the > > > > VHOST_IOTLB_INVALIDATE to get vhost_vdpa_as, the process is the > > > > same as VHOST_IOTLB_UPDATE > > > > > > > > Signed-off-by: Cindy Lu > > > > --- > > > > drivers/vhost/vdpa.c | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c > > > > index 7be9d9d8f01c..32636a02a0ab 100644 > > > > --- a/drivers/vhost/vdpa.c > > > > +++ b/drivers/vhost/vdpa.c > > > > @@ -1074,6 +1074,7 @@ static int vhost_vdpa_process_iotlb_msg(struc= t vhost_dev *dev, u32 asid, > > > > goto unlock; > > > > > > > > if (msg->type =3D=3D VHOST_IOTLB_UPDATE || > > > > + msg->type =3D=3D VHOST_IOTLB_INVALIDATE || > > > > > > I'm not sure I get here, invalidation doesn't need to create a new AS= . > > > > > > Or maybe you can post the userspace code that can trigger this issue? > > > > > > Thanks > > > > > sorry I didn't write it clearly > > For this issue can reproduce in vIOMMU no-batch mode support because > > while the vIOMMU enabled, it will > > flash a large memory to unmap, and this memory are haven't been mapped > > before, so this unmapping will fail > > > > qemu-system-x86_64: failed to write, fd=3D12, errno=3D14 (Bad address) > > qemu-system-x86_64: vhost_vdpa_dma_unmap(0x7fa26d1dd190, 0x0, > > 0x80000000) =3D -5 (Bad address) > > So if this is a simple unmap, which error condition had you met in > vhost_vdpa_process_iotlb_msg()? > > I think you need to trace to see what happens. For example: > this happens when vIOMMU enable and vdpa binds to vfio-pci run testpmd the qemu will unmapped whole memory that was used and then mapped the iommu MR section This memory much larger than the memory mapped to vdpa(this is what actually mapped to vdpa device in no-iommu MR) > 1) can the code pass asid_to_iotlb() > 2) if not, ASID 0 has been deleted since all the mappings have been unmap= ped > > if ASID 0 has been completely unmap, any reason we need to unmap it > again? And do we need to drop the vhost_vdpa_remove_as() from both > > 1) vhost_vdpa_unmap() > and > 2) vhost_vdpa_process_iotlb_msg() > ? > > Thanks > the code passed the asid_to_iotlb(), The iotlb is NULL at this situation and the vhost_vdpa_process_iotlb_msg will return fail. this will cause the mapping in qemu fail thanks cindy > > qemu-system-x86_64: failed to write, fd=3D12, errno=3D14 (Bad address) > > .... > > in batch mode this operation will begin with VHOST_IOTLB_BATCH_BEGIN, > > so don't have this issue > > > > Thanks > > cindy > > > > msg->type =3D=3D VHOST_IOTLB_BATCH_BEGIN) { > > > > as =3D vhost_vdpa_find_alloc_as(v, asid); > > > > if (!as) { > > > > -- > > > > 2.34.3 > > > > > > > > > >