On Thu, Aug 08, 2019 at 08:54:54PM +0800, Jason Wang wrote:
> I don't have any objection to convert to spinlock() but just want to
> know if any case that the above smp_mb() + counter looks good to you?
This email is horribly mangled, but I don't think mixing smb_mb() and
smp_load_acquire() woul
On Mon, Aug 12, 2019 at 05:49:08AM -0400, Michael S. Tsirkin wrote:
> On Mon, Aug 12, 2019 at 10:44:51AM +0800, Jason Wang wrote:
> >
> > On 2019/8/11 上午1:52, Michael S. Tsirkin wrote:
> > > On Fri, Aug 09, 2019 at 01:48:42AM -0400, Jason Wang wrote:
> > > > Hi all:
> > > >
> > > > This series tr
On Tue, Aug 13, 2019 at 04:31:07PM +0800, Jason Wang wrote:
> What kind of issues do you see? Spinlock is to synchronize GUP with MMU
> notifier in this series.
A GUP that can't sleep can't pagefault which makes it a really weird
pattern
> Btw, back to the original question. May I know why synch
On Thu, Aug 15, 2019 at 11:26:46AM +0800, Jason Wang wrote:
>
> On 2019/8/13 下午7:57, Jason Gunthorpe wrote:
> > On Tue, Aug 13, 2019 at 04:31:07PM +0800, Jason Wang wrote:
> >
> > > What kind of issues do you see? Spinlock is to synchronize GUP with MMU
> > >
On Thu, Aug 15, 2019 at 04:16:30PM -0400, Jerome Glisse wrote:
> On Thu, Aug 15, 2019 at 03:19:29PM -0400, Jerome Glisse wrote:
> > On Tue, Aug 13, 2019 at 02:01:35PM +0300, Adalbert Lazăr wrote:
> > > On Fri, 9 Aug 2019 09:24:44 -0700, Matthew Wilcox
> > > wrote:
> > > > On Fri, Aug 09, 2019 at
On Thu, Sep 05, 2019 at 08:27:34PM +0800, Jason Wang wrote:
> Hi:
>
> Per request from Michael and Jason, the metadata accelreation is
> reverted in this version and rework in next version.
>
> Please review.
>
> Thanks
>
> Jason Wang (2):
> Revert "vhost: access vq metadata through kernel vi
On Fri, Sep 06, 2019 at 06:02:35PM +0800, Jason Wang wrote:
>
> On 2019/9/5 下午9:59, Jason Gunthorpe wrote:
> > On Thu, Sep 05, 2019 at 08:27:34PM +0800, Jason Wang wrote:
> > > Hi:
> > >
> > > Per request from Michael and Jason, the metadata accelreatio
On Thu, Jan 16, 2020 at 08:42:29PM +0800, Jason Wang wrote:
> vDPA device is a device that uses a datapath which complies with the
> virtio specifications with vendor specific control path. vDPA devices
> can be both physically located on the hardware or emulated by
> software. vDPA hardware device
On Thu, Jan 16, 2020 at 08:42:30PM +0800, Jason Wang wrote:
> diff --git a/drivers/virtio/virtio_vdpa.c b/drivers/virtio/virtio_vdpa.c
> new file mode 100644
> index ..86936e5e7ec3
> +++ b/drivers/virtio/virtio_vdpa.c
> @@ -0,0 +1,400 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
On Thu, Jan 16, 2020 at 08:42:31PM +0800, Jason Wang wrote:
> This patch implements a software vDPA networking device. The datapath
> is implemented through vringh and workqueue. The device has an on-chip
> IOMMU which translates IOVA to PA. For kernel virtio drivers, vDPA
> simulator driver provid
On Fri, Jan 17, 2020 at 05:32:35PM +0800, Jason Wang wrote:
> >
> > > + const struct vdpa_config_ops *ops = vdpa->config;
> > > + struct virtio_vdpa_device *vd_dev;
> > > + int rc;
> > > +
> > > + vd_dev = devm_kzalloc(dev, sizeof(*vd_dev), GFP_KERNEL);
> > > + if (!vd_dev)
> > > + return
On Fri, Jan 17, 2020 at 05:32:39PM +0800, Jason Wang wrote:
>
> On 2020/1/16 下午11:47, Jason Gunthorpe wrote:
> > On Thu, Jan 16, 2020 at 08:42:31PM +0800, Jason Wang wrote:
> > > This patch implements a software vDPA networking device. The datapath
> > > is
On Fri, Jan 17, 2020 at 11:03:12AM +0800, Jason Wang wrote:
>
> On 2020/1/16 下午11:22, Jason Gunthorpe wrote:
> > On Thu, Jan 16, 2020 at 08:42:29PM +0800, Jason Wang wrote:
> > > vDPA device is a device that uses a datapath which complies with the
> > > virtio speci
On Mon, Jan 20, 2020 at 04:43:53PM +0800, Jason Wang wrote:
> This is similar to the design of platform IOMMU part of vhost-vdpa. We
> decide to send diffs to platform IOMMU there. If it's ok to do that in
> driver, we can replace set_map with incremental API like map()/unmap().
>
> Then driver ne
On Mon, Jan 20, 2020 at 07:17:26AM -0500, Michael S. Tsirkin wrote:
> On Fri, Jan 17, 2020 at 01:54:42PM +0000, Jason Gunthorpe wrote:
> > > 1) "virtio" vs "vhost", I implemented matching method for this in mdev
> > > series, but it looks unneces
On Tue, Jan 21, 2020 at 03:15:43AM -0500, Michael S. Tsirkin wrote:
> > This sounds more flexible e.g driver may choose to implement static mapping
> > one through commit. But a question here, it looks to me this still requires
> > the DMA to be synced with at least commit here. Otherwise device ma
On Mon, Jan 20, 2020 at 04:25:23PM -0500, Michael S. Tsirkin wrote:
> On Mon, Jan 20, 2020 at 08:51:43PM +, Shahaf Shuler wrote:
> > Monday, January 20, 2020 7:50 PM, Jason Gunthorpe:
> > > Subject: Re: [PATCH 3/5] vDPA: introduce vDPA bus
> > >
> > > On M
On Mon, Jan 20, 2020 at 04:56:06PM -0500, Michael S. Tsirkin wrote:
> > For vfio? vfio is the only thing I am aware doing
> > that, and this is not vfio..
>
> vfio is not doing anything. anyone can use a combination
> of unbind and driver_override to attach a driver to a device.
>
> It's not a gr
On Tue, Jan 21, 2020 at 09:15:14AM -0500, Michael S. Tsirkin wrote:
> On Tue, Jan 21, 2020 at 02:12:05PM +0000, Jason Gunthorpe wrote:
> > On Mon, Jan 20, 2020 at 04:56:06PM -0500, Michael S. Tsirkin wrote:
> > > > For vfio? vfio is the only thing I am aware doing
> >
On Tue, Feb 04, 2020 at 04:28:27PM +0800, Jason Wang wrote:
>
> On 2020/2/4 下午4:21, Zhu Lingshan wrote:
> > > +static const struct dma_map_ops vdpasim_dma_ops = {
> > > + .map_page = vdpasim_map_page,
> > > + .unmap_page = vdpasim_unmap_page,
> > > + .alloc = vdpasim_alloc_coherent,
> > >
On Wed, Feb 05, 2020 at 03:50:14PM +0800, Jason Wang wrote:
> > Would it be better for the map/umnap logic to happen inside each device ?
> > Devices that needs the IOMMU will call iommu APIs from inside the driver
> > callback.
>
> Technically, this can work. But if it can be done by vhost-vpda
On Mon, Feb 10, 2020 at 11:56:07AM +0800, Jason Wang wrote:
> This patch introduces a vDPA transport for virtio. This is used to
> use kernel virtio driver to drive the mediated device that is capable
> of populating virtqueue directly.
Is this comment still right? Is there a mediated device still
On Mon, Feb 10, 2020 at 11:56:06AM +0800, Jason Wang wrote:
> +/**
> + * vdpa_register_device - register a vDPA device
> + * Callers must have a succeed call of vdpa_init_device() before.
> + * @vdev: the vdpa device to be registered to vDPA bus
> + *
> + * Returns an error when fail to add to vDPA
On Mon, Feb 10, 2020 at 11:56:08AM +0800, Jason Wang wrote:
> +
> +static struct vdpasim *vdpasim_create(void)
> +{
> + struct vdpasim *vdpasim;
> + struct virtio_net_config *config;
> + struct vdpa_device *vdpa;
> + struct device *dev;
> + int ret = -ENOMEM;
> +
> + vdpasim
On Wed, Feb 12, 2020 at 03:55:31PM +0800, Jason Wang wrote:
> > The ida_simple_remove should probably be part of the class release
> > function to make everything work right
>
> It looks to me bus instead of class is the correct abstraction here since
> the devices share a set of programming inter
On Thu, Feb 13, 2020 at 11:34:10AM +0800, Jason Wang wrote:
> > You have dev, type or
> > class to choose from. Type is rarely used and doesn't seem to be used
> > by vdpa, so class seems the right choice
> >
> > Jason
>
> Yes, but my understanding is class and bus are mutually exclusive. So w
On Thu, Feb 13, 2020 at 10:58:44PM +0800, Jason Wang wrote:
>
> On 2020/2/13 下午9:41, Jason Gunthorpe wrote:
> > On Thu, Feb 13, 2020 at 11:34:10AM +0800, Jason Wang wrote:
> >
> > > >You have dev, type or
> > > > class to choose from. Type
On Thu, Feb 13, 2020 at 10:41:06AM -0500, Michael S. Tsirkin wrote:
> On Thu, Feb 13, 2020 at 11:05:42AM -0400, Jason Gunthorpe wrote:
> > On Thu, Feb 13, 2020 at 10:58:44PM +0800, Jason Wang wrote:
> > >
> > > On 2020/2/13 下午9:41, Jason Gunthorpe wrote:
> > >
On Thu, Feb 13, 2020 at 10:59:34AM -0500, Michael S. Tsirkin wrote:
> On Thu, Feb 13, 2020 at 11:51:54AM -0400, Jason Gunthorpe wrote:
> > The 'class' is supposed to provide all the library functions to remove
> > this duplication. Instead of plugging the HW driver in via
On Thu, Feb 13, 2020 at 10:56:00AM -0500, Michael S. Tsirkin wrote:
> On Thu, Feb 13, 2020 at 11:51:54AM -0400, Jason Gunthorpe wrote:
> > > That bus is exactly what Greg KH proposed. There are other ways
> > > to solve this I guess but this bikeshedding is getting tiring.
>
On Fri, Feb 14, 2020 at 11:23:27AM +0800, Jason Wang wrote:
> > > Though all vDPA devices have the same programming interface, but the
> > > semantic is different. So it looks to me that use bus complies what
> > > class.rst said:
> > >
> > > "
> > >
> > > Each device class defines a set of sema
On Fri, Feb 14, 2020 at 12:05:32PM +0800, Jason Wang wrote:
> > The standard driver model is a 'bus' driver provides the HW access
> > (think PCI level things), and a 'hw driver' attaches to the bus
> > device,
>
> This is not true, kernel had already had plenty virtual bus where virtual
> device
On Fri, Jan 31, 2020 at 11:36:51AM +0800, Tiwei Bie wrote:
> +static int vhost_vdpa_alloc_minor(struct vhost_vdpa *v)
> +{
> + return idr_alloc(&vhost_vdpa.idr, v, 0, MINORMASK + 1,
> + GFP_KERNEL);
> +}
Please don't use idr in new code, use xarray directly
> +static int
On Mon, Feb 17, 2020 at 02:08:03PM +0800, Jason Wang wrote:
> I thought you were copied in the patch [1], maybe we can move vhost related
> discussion there to avoid confusion.
>
> [1] https://lwn.net/Articles/811210/
Wow, that is .. confusing.
So this is supposed to duplicate the uAPI of vhost-
On Wed, Feb 19, 2020 at 01:35:25PM +0800, Jason Wang wrote:
> > But it is
> > open coded and duplicated because .. vdpa?
>
>
> I'm not sure I get here, vhost module is reused for vhost-vdpa and all
> current vhost device (e.g net) uses their own char device.
I mean there shouldn't be two fops im
On Wed, Feb 19, 2020 at 10:52:38AM +0800, Tiwei Bie wrote:
> > > +static int __init vhost_vdpa_init(void)
> > > +{
> > > + int r;
> > > +
> > > + idr_init(&vhost_vdpa.idr);
> > > + mutex_init(&vhost_vdpa.mutex);
> > > + init_waitqueue_head(&vhost_vdpa.release_q);
> > > +
> > > + /* /dev/vhost-vdpa/
On Thu, Feb 20, 2020 at 02:11:40PM +0800, Jason Wang wrote:
> +static int virtio_vdpa_probe(struct vdpa_device *vdpa)
> +{
> + const struct vdpa_config_ops *ops = vdpa->config;
> + struct virtio_vdpa_device *vd_dev;
> + int ret = -EINVAL;
> +
> + vd_dev = kzalloc(sizeof(*vd_dev), GF
On Thu, Feb 20, 2020 at 02:11:41PM +0800, Jason Wang wrote:
> +static void vdpasim_device_release(struct device *dev)
> +{
> + struct vdpasim *vdpasim = dev_to_sim(dev);
> +
> + cancel_work_sync(&vdpasim->work);
> + kfree(vdpasim->buffer);
> + vhost_iotlb_free(vdpasim->iommu);
> +
On Thu, Feb 20, 2020 at 02:11:39PM +0800, Jason Wang wrote:
> vDPA device is a device that uses a datapath which complies with the
> virtio specifications with vendor specific control path. vDPA devices
> can be both physically located on the hardware or emulated by
> software. vDPA hardware device
On Wed, Feb 26, 2020 at 02:12:26PM +0800, Jason Wang wrote:
> > > It is a bit weird to be creating this dummy parent, couldn't this be
> > > done by just passing a NULL parent to vdpa_alloc_device, doing
> > > set_dma_ops() on the vdpasim->vdpa->dev and setting dma_device to
> > > vdpasim->vdpa->de
On Wed, Feb 26, 2020 at 02:04:54PM +0800, Jason Wang wrote:
> +struct vdpa_device *vdpa_alloc_device(struct device *parent,
> + struct device *dma_dev,
> + const struct vdpa_config_ops *config)
> +{
> + struct vdpa_device *vdev
On Wed, Mar 18, 2020 at 04:03:27PM +0800, Jason Wang wrote:
> From: Zhu Lingshan
> +
> +static int ifcvf_vdpa_attach(struct ifcvf_adapter *adapter)
> +{
> + int ret;
> +
> + adapter->vdpa_dev = vdpa_alloc_device(adapter->dev, adapter->dev,
> +&i
On Thu, Mar 19, 2020 at 04:14:37PM +0800, Jason Wang wrote:
>
> On 2020/3/18 下午8:22, Jason Gunthorpe wrote:
> > On Wed, Mar 18, 2020 at 04:03:27PM +0800, Jason Wang wrote:
> > > From: Zhu Lingshan
> > > +
> > > +static int ifcvf_vdpa_attach(struct ifcvf_ada
On Wed, Mar 25, 2020 at 04:27:07PM +0800, Jason Wang wrote:
> +struct vdpa_device *__vdpa_alloc_device(struct device *parent,
> + const struct vdpa_config_ops *config,
> + size_t size);
> +
> +#define vdpa_alloc_device(dev_stru
On Wed, Mar 25, 2020 at 04:27:11PM +0800, Jason Wang wrote:
> +static int ifcvf_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> +{
> + struct device *dev = &pdev->dev;
> + struct ifcvf_adapter *adapter;
> + struct ifcvf_hw *vf;
> + int ret, i;
> +
> + ret = pci_ena
On Thu, Mar 26, 2020 at 01:50:53PM +0800, Jason Wang wrote:
> > > + adapter->vdpa.dma_dev = dev;
> > > + ret = vdpa_register_device(&adapter->vdpa);
> > > + if (ret) {
> > > + IFCVF_ERR(adapter->dev, "Failed to register ifcvf to vdpa bus");
> > > + goto err_msix;
> > > + }
> > > +
On Tue, Jun 09, 2020 at 01:45:53PM +0100, Kieran Bingham wrote:
> I wouldn't normally go through spelling fixes, but I caught sight of
> this typo twice, and then foolishly grepped the tree for it, and saw how
> pervasive it was.
>
> so here I am ... fixing a typo globally... but with an addition
On Wed, Aug 05, 2020 at 07:01:52PM +, Saeed Mahameed wrote:
> On Wed, 2020-08-05 at 09:12 -0400, Michael S. Tsirkin wrote:
> > On Wed, Aug 05, 2020 at 04:01:58PM +0300, Eli Cohen wrote:
> > > On Wed, Aug 05, 2020 at 08:48:52AM -0400, Michael S. Tsirkin wrote:
> > > > > Did you merge this?:
> >
On Tue, Oct 15, 2024 at 11:19:33AM +0800, Zhangfei Gao wrote:
> > +static int iommufd_fault_iopf_enable(struct iommufd_device *idev)
> > +{
> > + struct device *dev = idev->dev;
> > + int ret;
> > +
> > + /*
> > +* Once we turn on PCI/PRI support for VF, the response failu
On Fri, Oct 18, 2024 at 09:58:37AM +0800, Baolu Lu wrote:
> On 2024/10/17 21:08, Jason Gunthorpe wrote:
> > On Thu, Oct 17, 2024 at 08:35:24PM +0800, Zhangfei Gao wrote:
> >
> > > Yes, you are right
> > > I am using SRIOV vf and stall feature, so is_virtfn ==
On Wed, Oct 16, 2024 at 09:58:36AM +0800, Zhangfei Gao wrote:
> On Tue, 15 Oct 2024 at 20:54, Jason Gunthorpe wrote:
> >
> > On Tue, Oct 15, 2024 at 11:19:33AM +0800, Zhangfei Gao wrote:
> > > > +static int iommufd_fault_iopf_enable(struct iommufd_device *idev)
> &
On Wed, Oct 16, 2024 at 12:25:03PM -0300, Jason Gunthorpe wrote:
> > > smmu-v3 needs some more fixing to move that
> > > arm_smmu_master_enable_sva() logic into domain attachment.
> >
> > Will think about this, Thanks Jason
>
> Can you test it if a patch is ma
On Thu, Oct 17, 2024 at 09:44:18AM +0800, Zhangfei Gao wrote:
> On Wed, 16 Oct 2024 at 23:25, Jason Gunthorpe wrote:
> >
> > On Wed, Oct 16, 2024 at 09:58:36AM +0800, Zhangfei Gao wrote:
> > > On Tue, 15 Oct 2024 at 20:54, Jason Gunthorpe wrote:
> > > >
> &
On Thu, Oct 17, 2024 at 08:35:24PM +0800, Zhangfei Gao wrote:
> Yes, you are right
> I am using SRIOV vf and stall feature, so is_virtfn == true
>
> Our ACC devices are fake pci endpoint devices which supports stall,
> And they also supports sriov
>
> So I have to ignore the limitation.
I see,
On Tue, Oct 22, 2024 at 10:30:10PM +0800, Zhangfei Gao wrote:
> On Fri, 18 Oct 2024 at 21:53, Jason Gunthorpe wrote:
> >
> > On Wed, Oct 16, 2024 at 12:25:03PM -0300, Jason Gunthorpe wrote:
> > > > > smmu-v3 needs some more fixing to move that
> > > >
101 - 155 of 155 matches
Mail list logo
