Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1900805pxa; Thu, 6 Aug 2020 20:08:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyDnGLz2aHYQqyag4WijRg8JkAHSYlVJMIZR5/36hdfzJIYYr1CIkrtT2Uh4VjohFi1AlNh X-Received: by 2002:a17:906:c04d:: with SMTP id bm13mr7172964ejb.321.1596769686225; Thu, 06 Aug 2020 20:08:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596769686; cv=none; d=google.com; s=arc-20160816; b=mp3Q2ecfzdczNBHfFS6Aj8sVLaDz4swdHhfgVP7lwZ/sNckWKIfU9eJX+7k8wKMLq3 tWewwh5JsC+L1oQmxBIvcQtEV3jiqz/ho1jIizqNmBSt5IZrSF2yGSPWED5NIXkiCPVh G90izraIgOJFI8kbY3obiBl7shqORdeCcaOPsqbh/RRHc1NrrE/F0E3SG9vKk/PDDcSs hP4G3B0bo5UU8+TZgMJALxvWbxrlcdU4+ptWsOMB2BQYzuTJQZRh0rvFd7Mjvqc2Uqnz oBcXp+nYWHkW8q3Fm/CfYpyQKEh/q3ig5JncmJD4dO3mfZasWpyFxTDHHrR+Fsg86Ih3 a6Yg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=xdOpBjCOVkquS5JtoOdSjXeW1osIHL7KNsSvy/tC5XQ=; b=VH/QO+wv8jG2ib7tYKUIqVCWN0CmhOTazKOFWTnV51X/seBQEsOD8380MWCuHvDgYv Vt2ow19O6/DsNSXfnuyOKEAPZ1nq4jXD68AeeVauVPCYJcL4xtzKO8hHpr38hF5Ui58M +qag96SASNhK6lRRTJWPaPru+wld+ryzERBR8g/LNr+Yl/N4fW58yN88Z9DVMNHAIM38 AZFRtUd8QRMzjv9NGGrn8WX8SWNaEi2NK9jBYq1x2k6yQBQKkUPMPnYUNtzhfcNZjzWR 3ygDrvd08D6PqWnTZNsCr0cRN7PY/WuGA5Vyr78qxWXHzYA2jRmAS6Fwh9rYq6Qp03zy ACsA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=OVmkxO5t; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v15si4439012edy.90.2020.08.06.20.07.30; Thu, 06 Aug 2020 20:08:06 -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=@redhat.com header.s=mimecast20190719 header.b=OVmkxO5t; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726104AbgHGDEs (ORCPT + 99 others); Thu, 6 Aug 2020 23:04:48 -0400 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:33889 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726038AbgHGDEs (ORCPT ); Thu, 6 Aug 2020 23:04:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1596769486; 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=xdOpBjCOVkquS5JtoOdSjXeW1osIHL7KNsSvy/tC5XQ=; b=OVmkxO5tYQye9xvQs1JjLKVg2PGjIBymQqDpPz3qJoIoneGa5fKFzDxgh3GmOtsnyrT0R3 A4lITw/5xeeFgyr2eKhQohG3Xtvku8B651wN4UY+W8Q2cDAg5oQ1rjdEJIyH39IaDp0M1H TBVU7Hvs8DlO2CpdQW4adldABODCujM= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-288-olBv4X8GPxauTGFiSuf8pw-1; Thu, 06 Aug 2020 23:04:42 -0400 X-MC-Unique: olBv4X8GPxauTGFiSuf8pw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7D8B0106B242; Fri, 7 Aug 2020 03:04:40 +0000 (UTC) Received: from [10.72.13.215] (ovpn-13-215.pek2.redhat.com [10.72.13.215]) by smtp.corp.redhat.com (Postfix) with ESMTP id C5C597B927; Fri, 7 Aug 2020 03:04:32 +0000 (UTC) Subject: Re: [PATCH 1/4] vdpa: introduce config op to get valid iova range To: Eli Cohen Cc: "mst@redhat.com" , "virtualization@lists.linux-foundation.org" , "linux-kernel@vger.kernel.org" , "rob.miller@broadcom.com" , "lingshan.zhu@intel.com" , "eperezma@redhat.com" , "lulu@redhat.com" , Shahaf Shuler , "hanand@xilinx.com" , "mhabets@solarflare.com" , "gdawar@xilinx.com" , "saugatm@xilinx.com" , "vmireyno@marvell.com" , "zhangweining@ruijie.com.cn" References: <20200617032947.6371-1-jasowang@redhat.com> <20200617032947.6371-2-jasowang@redhat.com> <20200806121002.GA171574@mtl-vdi-166.wap.labs.mlnx> From: Jason Wang Message-ID: Date: Fri, 7 Aug 2020 11:04:30 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200806121002.GA171574@mtl-vdi-166.wap.labs.mlnx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/8/6 下午8:10, Eli Cohen wrote: > On Wed, Jun 17, 2020 at 06:29:44AM +0300, Jason Wang wrote: >> This patch introduce a config op to get valid iova range from the vDPA >> device. >> >> Signed-off-by: Jason Wang >> --- >> include/linux/vdpa.h | 14 ++++++++++++++ >> 1 file changed, 14 insertions(+) >> >> diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h >> index 239db794357c..b7633ed2500c 100644 >> --- a/include/linux/vdpa.h >> +++ b/include/linux/vdpa.h >> @@ -41,6 +41,16 @@ struct vdpa_device { >> unsigned int index; >> }; >> >> +/** >> + * vDPA IOVA range - the IOVA range support by the device >> + * @start: start of the IOVA range >> + * @end: end of the IOVA range >> + */ >> +struct vdpa_iova_range { >> + u64 start; >> + u64 end; >> +}; >> + > What do you do with this information? Suppose some device tells you it > supports some limited range, say, from 0x40000000 to 0x80000000. What > does qemu do with this information? For qemu, when qemu will fail the vDPA device creation when: 1) vIOMMU is not enabled and GPA is out of this range 2) vIOMMU is enabled but it can't report such range to guest For other userspace application, it will know it can only use this range as its IOVA. Thanks