Re: [PATCH] vhost: introduce vDPA based backend

[Jason Wang]

On 2020/2/5 äå2:30, Michael S. Tsirkin wrote:
> On Wed, Feb 05, 2020 at 01:50:28PM +0800, Jason Wang wrote:
> > On 2020/2/5 äå1:31, Michael S. Tsirkin wrote:
> > > On Wed, Feb 05, 2020 at 11:12:21AM +0800, Jason Wang wrote:
> > > > On 2020/2/5 äå10:05, Tiwei Bie wrote:
> > > > > On Tue, Feb 04, 2020 at 02:46:16PM +0800, Jason Wang wrote:
> > > > > > On 2020/2/4 äå2:01, Michael S. Tsirkin wrote:
> > > > > > > On Tue, Feb 04, 2020 at 11:30:11AM +0800, Jason Wang wrote:
> > > > > > > > 5) generate diffs of memory table and using IOMMU API to setup the dma
> > > > > > > > mapping in this method
> > > > > > > Frankly I think that's a bunch of work. Why not a MAP/UNMAP interface?
> > > > > > Sure, so that basically VHOST_IOTLB_UPDATE/INVALIDATE I think?
> > > > > Do you mean we let userspace to only use VHOST_IOTLB_UPDATE/INVALIDATE
> > > > > to do the DMA mapping in vhost-vdpa case? When vIOMMU isn't available,
> > > > > userspace will set msg->iova to GPA, otherwise userspace will set
> > > > > msg->iova to GIOVA, and vhost-vdpa module will get HPA from msg->uaddr?
> > > > >
> > > > > Thanks,
> > > > > Tiwei
> > > > I think so. Michael, do you think this makes sense?
> > > >
> > > > Thanks
> > > to make sure, could you post the suggested argument format for
> > > these ioctls?
> > It's the existed uapi:
> >
> > /* no alignment requirement */
> > struct vhost_iotlb_msg {
> >  ÂÂÂ __u64 iova;
> >  ÂÂÂ __u64 size;
> >  ÂÂÂ __u64 uaddr;
> > #define VHOST_ACCESS_ROÂÂÂÂÂ 0x1
> > #define VHOST_ACCESS_WOÂÂÂÂÂ 0x2
> > #define VHOST_ACCESS_RWÂÂÂÂÂ 0x3
> >  ÂÂÂ __u8 perm;
> > #define VHOST_IOTLB_MISSÂÂÂÂÂÂÂÂÂÂ 1
> > #define VHOST_IOTLB_UPDATEÂÂÂÂÂÂÂÂ 2
> > #define VHOST_IOTLB_INVALIDATEÂÂÂÂ 3
> > #define VHOST_IOTLB_ACCESS_FAILÂÂÂ 4
> >  ÂÂÂ __u8 type;
> > };
> >
> > #define VHOST_IOTLB_MSG 0x1
> > #define VHOST_IOTLB_MSG_V2 0x2
> >
> > struct vhost_msg {
> >  ÂÂÂ int type;
> >  ÂÂÂ union {
> >  ÂÂÂ ÂÂÂ struct vhost_iotlb_msg iotlb;
> >  ÂÂÂ ÂÂÂ __u8 padding[64];
> >  ÂÂÂ };
> > };
> >
> > struct vhost_msg_v2 {
> >  ÂÂÂ __u32 type;
> >  ÂÂÂ __u32 reserved;
> >  ÂÂÂ union {
> >  ÂÂÂ ÂÂÂ struct vhost_iotlb_msg iotlb;
> >  ÂÂÂ ÂÂÂ __u8 padding[64];
> >  ÂÂÂ };
> > };
> Oh ok.  So with a real device, I suspect we do not want to wait for each
> change to be processed by device completely, so we might want an asynchronous variant
> and then some kind of flush that tells device "you better apply these now".


Let me explain:

There are two types of devices:

1) device without on-chip IOMMU, DMA was done via IOMMU API which only 
support incremental map/unmap
2) device with on-chip IOMMU, DMA could be done by device driver itself, 
and we could choose to pass the whole mappings to the driver at one time 
through vDPA bus operation (set_map)

For vhost-vpda, there're two types of memory mapping:

a) memory table, setup by userspace through VHOST_SET_MEM_TABLE, the 
whole mapping is updated in this way
b) IOTLB API, incrementally done by userspace through vhost message 
(IOTLB_UPDATE/IOTLB_INVALIDATE)

The current design is:

- Reuse VHOST_SET_MEM_TABLE, and for type 1), we can choose to send 
diffs through IOMMU API or flush all the mappings then map new ones. For 
type 2), just send the whole mapping through set_map()
- Reuse vhost IOTLB, so for type 1), simply forward update/invalidate 
request via IOMMU API, for type 2), send IOTLB to vDPA device driver via 
set_map(), device driver may choose to send diffs or rebuild all mapping 
at their will

Technically we can use vhost IOTLB API (map/umap) for building 
VHOST_SET_MEM_TABLE, but to avoid device to process the each request, it 
looks to me we need new UAPI which seems sub optimal.

What's you thought?

Thanks


>