From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by dpdk.org (Postfix) with ESMTP id B8636567C for ; Mon, 18 Jan 2016 07:45:41 +0100 (CET) Received: by mail-pa0-f43.google.com with SMTP id yy13so336352332pab.3 for ; Sun, 17 Jan 2016 22:45:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mvista-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e8k594h641e6foOQrkYkWRr3ZrTH61oyuF1kaKEkxQU=; b=qnuk5bcgsNcKqRZ0whZ6w1Nw9FQHewfTkQoZgQTcZ+GaQ+v0unmx7LPC/OaofxoHMi rfpMEozucoo8ZB93u3awV/yCj9GJDgsCVsopduBw31pLATQeFZpBm+MwwJ2TLxrPFON4 VKzCm/WN4QXCKcNSZW62xYDIewh/N8I3+QEunVx2EUArbjrrAEIRD+rxkm8k9asDH9Th U8MRI729WTm8kpvOODRuRNwsZIGo0+w1UrSObZJS11Rbpehz10mT06FobV9J9fpJwTXy B0D3D5oXEBwXgaHh96N678vBWJ3hCvsZybgjCAZawvHEDY9C48xYy6ekbd9Vkqq0Driu ubgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=e8k594h641e6foOQrkYkWRr3ZrTH61oyuF1kaKEkxQU=; b=m3oQBjsP4V6+5cEfF7YWTGbYeIp+lyu6G+tsnkLZg/8bTYSmroqTyA5zLFJERE5WQ3 uofFi1Djg8k7M/axfFmxfyr39kFrERghF3PNH0cyCPHFlfYqCrSYgAEOmwASwOOu83Ua iD8q8XGDavWo5Igg9qrdLdwKBRGGFqF+bedXY65vidtWms/8AlcoS0QjoHTxQLAOdCLc jrkOfrGvocUdjnl9cPQ+uJLDhdTK9tyf4F/cjC3DOwbUHUWc3H7HueHqmeQPnRKMGEts R+wlArkzRWZ4Yu1ihbWkCn60q+srtQiPvbhCLZVb2SP3LHiZIQ7JnUlniQoSRjbWKZpJ Fmmg== X-Gm-Message-State: ALoCoQneMpW4yZ5zO4PeBkvXwfPOEE0uTEgQLe8KytU4ZK3t4Z4HvN4INGG0DCqAAf+S8YIyPPmAahkG0OusKe5KMQFmnGco0X00UkgwNwR0RGiuJ/5p4BE= MIME-Version: 1.0 X-Received: by 10.66.163.231 with SMTP id yl7mr33390804pab.141.1453099541062; Sun, 17 Jan 2016 22:45:41 -0800 (PST) Received: by 10.66.196.81 with HTTP; Sun, 17 Jan 2016 22:45:40 -0800 (PST) In-Reply-To: <20160118061125.GW19531@yliu-dev.sh.intel.com> References: <1452778117-30178-1-git-send-email-sshukla@mvista.com> <1452778117-30178-9-git-send-email-sshukla@mvista.com> <20160115062726.GS19531@yliu-dev.sh.intel.com> <20160118061125.GW19531@yliu-dev.sh.intel.com> Date: Mon, 18 Jan 2016 12:15:40 +0530 Message-ID: From: Santosh Shukla To: Yuanhan Liu Content-Type: text/plain; charset=UTF-8 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v4 08/14] virtio: pci: extend virtio pci rw api for vfio interface X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 06:45:42 -0000 On Mon, Jan 18, 2016 at 11:41 AM, Yuanhan Liu wrote: > On Fri, Jan 15, 2016 at 07:12:04PM +0530, Santosh Shukla wrote: >> On Fri, Jan 15, 2016 at 6:13 PM, Santosh Shukla wrote: >> > On Fri, Jan 15, 2016 at 11:57 AM, Yuanhan Liu >> > wrote: >> >> On Thu, Jan 14, 2016 at 06:58:31PM +0530, Santosh Shukla wrote: >> >>> So far virtio handle rw access for uio / ioport interface, This patch to extend >> >>> the support for vfio interface. For that introducing private struct >> >>> virtio_vfio_dev{ >> >>> - is_vfio >> >>> - pci_dev >> >>> }; >> >>> Signed-off-by: Santosh Shukla >> >> ... >> >>> +/* For vfio only */ >> >>> +struct virtio_vfio_dev { >> >>> + bool is_vfio; /* True: vfio i/f, >> >>> + * False: not a vfio i/f >> >> >> >> Well, this is weird; you are adding a flag to tell whether it's a >> >> vfio device __inside__ a vfio struct. >> >> >> >> Back to the topic, this flag is not necessary to me: you can >> >> check the pci_dev->kdrv flag. >> >> >> > >> > yes, I'll replace is_vfio with pci_dev->kdrv. >> > >> >>> + */ >> >>> + struct rte_pci_device *pci_dev; /* vfio dev */ >> >> >> >> Note that I have already added this field into virtio_hw struct >> >> at my latest virtio 1.0 pmd patchset. >> >> >> >> While I told you before that you should not develop patches based >> >> on my patcheset, I guess you can do that now. Since it should be >> >> in good shape and close to be merged. >> > >> > Okay, Before rebasing my v5 patch on your 1.0 virtio patch, I like to >> > understand which qemu version support virtio 1.0 spec? >> >> Ignore, I figured out in other thread, >> qemu version >2.4, such as 2.4.1 or 2.5.0. > > It will not matter. You can continue using the old legacy virtio, which > is the default case: my patchset keeps the backward compatibility. > > What's worty noting is that virtio 1.0 uses memory mmaped bar space for > configuration, instead of ioport reading/writing. Therefore, I'd suggest > you to keep testing with legacy virtio, to make sure the VFIO stuff works. > And off course, virtio 1.0 testing is also welcome, to make sure it works > on ARM as well. > I am testing for virtio 1.0 and 0.95 for arm including your patch, soon we;ll post the patch series that is rebased on / dependent on below patchset: - virtio 1.0 - vfio-noiommu - KDRV check by huawei IMO, we should start merging the dependent patches as because I'll have to rebase, then do regression across the platform at least for x86/arm64 and it's quite a work now. Beside that I have few question specific to vfio in virtio pmd driver; - vfio don't need resource_init functionality as it uses struct rte_pci_dev but it need parsing so to make sure 1. user has setted no_iommu mode 2. virtio pci device attached to vfio-no-iommu driver or not. So for 1) I am thinking to add RTE_KDRV_VFIO_NOIOMMU mode and a helper function like pci_vfio_is_iommu(), such that pc_xxx_scan() function updates dev->kdrv with RTE_KDRV_VFIO_NOIOMMU at driver probe time. case 2) would check for _noiommu mode and then would verify that driver is attached or not? above two case applicable to both virtio spec 1.0 and 0.95. I have done changes for those two case for v5 patch series,l any comment welcome before I push patch for review. Thanks. > --yliu