* [PATCH v10 01/17] iova: Export alloc_iova_fast() and free_iova_fast()
2021-07-29 7:34 [PATCH v10 00/17] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
@ 2021-07-29 7:34 ` Xie Yongji
2021-08-03 7:41 ` Jason Wang
2021-08-03 7:41 ` Jason Wang
2021-07-29 7:34 ` [PATCH v10 02/17] file: Export receive_fd() to modules Xie Yongji
` (15 subsequent siblings)
16 siblings, 2 replies; 55+ messages in thread
From: Xie Yongji @ 2021-07-29 7:34 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu, joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
Export alloc_iova_fast() and free_iova_fast() so that
some modules can use it to improve iova allocation efficiency.
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
---
drivers/iommu/iova.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index b6cf5f16123b..3941ed6bb99b 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -521,6 +521,7 @@ alloc_iova_fast(struct iova_domain *iovad, unsigned long size,
return new_iova->pfn_lo;
}
+EXPORT_SYMBOL_GPL(alloc_iova_fast);
/**
* free_iova_fast - free iova pfn range into rcache
@@ -538,6 +539,7 @@ free_iova_fast(struct iova_domain *iovad, unsigned long pfn, unsigned long size)
free_iova(iovad, pfn);
}
+EXPORT_SYMBOL_GPL(free_iova_fast);
#define fq_ring_for_each(i, fq) \
for ((i) = (fq)->head; (i) != (fq)->tail; (i) = ((i) + 1) % IOVA_FQ_SIZE)
--
2.11.0
^ permalink raw reply related [flat|nested] 55+ messages in thread* Re: [PATCH v10 01/17] iova: Export alloc_iova_fast() and free_iova_fast()
2021-07-29 7:34 ` [PATCH v10 01/17] iova: Export alloc_iova_fast() and free_iova_fast() Xie Yongji
@ 2021-08-03 7:41 ` Jason Wang
2021-08-03 7:41 ` Jason Wang
1 sibling, 0 replies; 55+ messages in thread
From: Jason Wang @ 2021-08-03 7:41 UTC (permalink / raw)
To: Xie Yongji, mst, stefanha, sgarzare, parav, hch,
christian.brauner, rdunlap, willy, viro, axboe, bcrl, corbet,
mika.penttila, dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu,
joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
在 2021/7/29 下午3:34, Xie Yongji 写道:
> Export alloc_iova_fast() and free_iova_fast() so that
> some modules can use it to improve iova allocation efficiency.
It's better to explain which alloc_iova() is not sufficient here.
Thanks
>
> Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> ---
> drivers/iommu/iova.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
> index b6cf5f16123b..3941ed6bb99b 100644
> --- a/drivers/iommu/iova.c
> +++ b/drivers/iommu/iova.c
> @@ -521,6 +521,7 @@ alloc_iova_fast(struct iova_domain *iovad, unsigned long size,
>
> return new_iova->pfn_lo;
> }
> +EXPORT_SYMBOL_GPL(alloc_iova_fast);
>
> /**
> * free_iova_fast - free iova pfn range into rcache
> @@ -538,6 +539,7 @@ free_iova_fast(struct iova_domain *iovad, unsigned long pfn, unsigned long size)
>
> free_iova(iovad, pfn);
> }
> +EXPORT_SYMBOL_GPL(free_iova_fast);
>
> #define fq_ring_for_each(i, fq) \
> for ((i) = (fq)->head; (i) != (fq)->tail; (i) = ((i) + 1) % IOVA_FQ_SIZE)
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH v10 01/17] iova: Export alloc_iova_fast() and free_iova_fast()
2021-07-29 7:34 ` [PATCH v10 01/17] iova: Export alloc_iova_fast() and free_iova_fast() Xie Yongji
2021-08-03 7:41 ` Jason Wang
@ 2021-08-03 7:41 ` Jason Wang
2021-08-03 8:54 ` Yongji Xie
1 sibling, 1 reply; 55+ messages in thread
From: Jason Wang @ 2021-08-03 7:41 UTC (permalink / raw)
To: Xie Yongji, mst, stefanha, sgarzare, parav, hch,
christian.brauner, rdunlap, willy, viro, axboe, bcrl, corbet,
mika.penttila, dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu,
joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
在 2021/7/29 下午3:34, Xie Yongji 写道:
> Export alloc_iova_fast() and free_iova_fast() so that
> some modules can use it to improve iova allocation efficiency.
It's better to explain why alloc_iova() is not sufficient here.
Thanks
>
> Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> ---
> drivers/iommu/iova.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
> index b6cf5f16123b..3941ed6bb99b 100644
> --- a/drivers/iommu/iova.c
> +++ b/drivers/iommu/iova.c
> @@ -521,6 +521,7 @@ alloc_iova_fast(struct iova_domain *iovad, unsigned long size,
>
> return new_iova->pfn_lo;
> }
> +EXPORT_SYMBOL_GPL(alloc_iova_fast);
>
> /**
> * free_iova_fast - free iova pfn range into rcache
> @@ -538,6 +539,7 @@ free_iova_fast(struct iova_domain *iovad, unsigned long pfn, unsigned long size)
>
> free_iova(iovad, pfn);
> }
> +EXPORT_SYMBOL_GPL(free_iova_fast);
>
> #define fq_ring_for_each(i, fq) \
> for ((i) = (fq)->head; (i) != (fq)->tail; (i) = ((i) + 1) % IOVA_FQ_SIZE)
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH v10 01/17] iova: Export alloc_iova_fast() and free_iova_fast()
2021-08-03 7:41 ` Jason Wang
@ 2021-08-03 8:54 ` Yongji Xie
2021-08-03 10:53 ` Robin Murphy
0 siblings, 1 reply; 55+ messages in thread
From: Yongji Xie @ 2021-08-03 8:54 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, Greg KH, He Zhe, Liu Xiaodong, Joe Perches,
songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
On Tue, Aug 3, 2021 at 3:41 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/7/29 下午3:34, Xie Yongji 写道:
> > Export alloc_iova_fast() and free_iova_fast() so that
> > some modules can use it to improve iova allocation efficiency.
>
>
> It's better to explain why alloc_iova() is not sufficient here.
>
Fine.
Thanks,
Yongji
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH v10 01/17] iova: Export alloc_iova_fast() and free_iova_fast()
2021-08-03 8:54 ` Yongji Xie
@ 2021-08-03 10:53 ` Robin Murphy
2021-08-04 5:02 ` Yongji Xie
0 siblings, 1 reply; 55+ messages in thread
From: Robin Murphy @ 2021-08-03 10:53 UTC (permalink / raw)
To: Yongji Xie, Jason Wang
Cc: kvm, Michael S. Tsirkin, virtualization, Christian Brauner,
Jonathan Corbet, Matthew Wilcox, Christoph Hellwig,
Dan Carpenter, Stefano Garzarella, Liu Xiaodong, linux-fsdevel,
Al Viro, Stefan Hajnoczi, songmuchun, Jens Axboe, He Zhe,
Greg KH, Randy Dunlap, linux-kernel, iommu, bcrl, netdev,
Joe Perches, Mika Penttilä
On 2021-08-03 09:54, Yongji Xie wrote:
> On Tue, Aug 3, 2021 at 3:41 PM Jason Wang <jasowang@redhat.com> wrote:
>>
>>
>> 在 2021/7/29 下午3:34, Xie Yongji 写道:
>>> Export alloc_iova_fast() and free_iova_fast() so that
>>> some modules can use it to improve iova allocation efficiency.
>>
>>
>> It's better to explain why alloc_iova() is not sufficient here.
>>
>
> Fine.
What I fail to understand from the later patches is what the IOVA domain
actually represents. If the "device" is a userspace process then
logically the "IOVA" would be the userspace address, so presumably
somewhere you're having to translate between this arbitrary address
space and actual usable addresses - if you're worried about efficiency
surely it would be even better to not do that?
Presumably userspace doesn't have any concern about alignment and the
things we have to worry about for the DMA API in general, so it's pretty
much just allocating slots in a buffer, and there are far more effective
ways to do that than a full-blown address space manager. If you're going
to reuse any infrastructure I'd have expected it to be SWIOTLB rather
than the IOVA allocator. Because, y'know, you're *literally implementing
a software I/O TLB* ;)
Robin.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH v10 01/17] iova: Export alloc_iova_fast() and free_iova_fast()
2021-08-03 10:53 ` Robin Murphy
@ 2021-08-04 5:02 ` Yongji Xie
2021-08-04 15:43 ` Robin Murphy
0 siblings, 1 reply; 55+ messages in thread
From: Yongji Xie @ 2021-08-04 5:02 UTC (permalink / raw)
To: Robin Murphy
Cc: Jason Wang, kvm, Michael S. Tsirkin, virtualization,
Christian Brauner, Jonathan Corbet, Matthew Wilcox,
Christoph Hellwig, Dan Carpenter, Stefano Garzarella,
Liu Xiaodong, linux-fsdevel, Al Viro, Stefan Hajnoczi,
songmuchun, Jens Axboe, He Zhe, Greg KH, Randy Dunlap,
linux-kernel, iommu, bcrl, netdev, Joe Perches,
Mika Penttilä
On Tue, Aug 3, 2021 at 6:54 PM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2021-08-03 09:54, Yongji Xie wrote:
> > On Tue, Aug 3, 2021 at 3:41 PM Jason Wang <jasowang@redhat.com> wrote:
> >>
> >>
> >> 在 2021/7/29 下午3:34, Xie Yongji 写道:
> >>> Export alloc_iova_fast() and free_iova_fast() so that
> >>> some modules can use it to improve iova allocation efficiency.
> >>
> >>
> >> It's better to explain why alloc_iova() is not sufficient here.
> >>
> >
> > Fine.
>
> What I fail to understand from the later patches is what the IOVA domain
> actually represents. If the "device" is a userspace process then
> logically the "IOVA" would be the userspace address, so presumably
> somewhere you're having to translate between this arbitrary address
> space and actual usable addresses - if you're worried about efficiency
> surely it would be even better to not do that?
>
Yes, userspace daemon needs to translate the "IOVA" in a DMA
descriptor to the VA (from mmap(2)). But this actually doesn't affect
performance since it's an identical mapping in most cases.
> Presumably userspace doesn't have any concern about alignment and the
> things we have to worry about for the DMA API in general, so it's pretty
> much just allocating slots in a buffer, and there are far more effective
> ways to do that than a full-blown address space manager.
Considering iova allocation efficiency, I think the iova allocator is
better here. In most cases, we don't even need to hold a spin lock
during iova allocation.
> If you're going
> to reuse any infrastructure I'd have expected it to be SWIOTLB rather
> than the IOVA allocator. Because, y'know, you're *literally implementing
> a software I/O TLB* ;)
>
But actually what we can reuse in SWIOTLB is the IOVA allocator. And
the IOVA management in SWIOTLB is not what we want. For example,
SWIOTLB allocates and uses contiguous memory for bouncing, which is
not necessary in VDUSE case. And VDUSE needs coherent mapping which is
not supported by the SWIOTLB. Besides, the SWIOTLB works in singleton
mode (designed for platform IOMMU) , but VDUSE is based on on-chip
IOMMU (supports multiple instances). So I still prefer to reuse the
IOVA allocator to implement a MMU-based software IOTLB.
Thanks,
Yongji
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH v10 01/17] iova: Export alloc_iova_fast() and free_iova_fast()
2021-08-04 5:02 ` Yongji Xie
@ 2021-08-04 15:43 ` Robin Murphy
2021-08-05 12:34 ` Yongji Xie
0 siblings, 1 reply; 55+ messages in thread
From: Robin Murphy @ 2021-08-04 15:43 UTC (permalink / raw)
To: Yongji Xie
Cc: kvm, Michael S. Tsirkin, Jason Wang, virtualization,
Christian Brauner, Jonathan Corbet, Matthew Wilcox,
Christoph Hellwig, Dan Carpenter, Stefano Garzarella,
Liu Xiaodong, Joe Perches, Al Viro, Stefan Hajnoczi, songmuchun,
Jens Axboe, He Zhe, Greg KH, Randy Dunlap, linux-kernel, iommu,
bcrl, netdev, linux-fsdevel, Mika Penttilä
On 2021-08-04 06:02, Yongji Xie wrote:
> On Tue, Aug 3, 2021 at 6:54 PM Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> On 2021-08-03 09:54, Yongji Xie wrote:
>>> On Tue, Aug 3, 2021 at 3:41 PM Jason Wang <jasowang@redhat.com> wrote:
>>>>
>>>>
>>>> 在 2021/7/29 下午3:34, Xie Yongji 写道:
>>>>> Export alloc_iova_fast() and free_iova_fast() so that
>>>>> some modules can use it to improve iova allocation efficiency.
>>>>
>>>>
>>>> It's better to explain why alloc_iova() is not sufficient here.
>>>>
>>>
>>> Fine.
>>
>> What I fail to understand from the later patches is what the IOVA domain
>> actually represents. If the "device" is a userspace process then
>> logically the "IOVA" would be the userspace address, so presumably
>> somewhere you're having to translate between this arbitrary address
>> space and actual usable addresses - if you're worried about efficiency
>> surely it would be even better to not do that?
>>
>
> Yes, userspace daemon needs to translate the "IOVA" in a DMA
> descriptor to the VA (from mmap(2)). But this actually doesn't affect
> performance since it's an identical mapping in most cases.
I'm not familiar with the vhost_iotlb stuff, but it looks suspiciously
like you're walking yet another tree to make those translations. Even if
the buffer can be mapped all at once with a fixed offset such that each
DMA mapping call doesn't need a lookup for each individual "IOVA" - that
might be what's happening already, but it's a bit hard to follow just
reading the patches in my mail client - vhost_iotlb_add_range() doesn't
look like it's super-cheap to call, and you're serialising on a lock for
that.
My main point, though, is that if you've already got something else
keeping track of the actual addresses, then the way you're using an
iova_domain appears to be something you could do with a trivial bitmap
allocator. That's why I don't buy the efficiency argument. The main
design points of the IOVA allocator are to manage large address spaces
while trying to maximise spatial locality to minimise the underlying
pagetable usage, and allocating with a flexible limit to support
multiple devices with different addressing capabilities in the same
address space. If none of those aspects are relevant to the use-case -
which AFAICS appears to be true here - then as a general-purpose
resource allocator it's rubbish and has an unreasonably massive memory
overhead and there are many, many better choices.
FWIW I've recently started thinking about moving all the caching stuff
out of iova_domain and into the iommu-dma layer since it's now a giant
waste of space for all the other current IOVA users.
>> Presumably userspace doesn't have any concern about alignment and the
>> things we have to worry about for the DMA API in general, so it's pretty
>> much just allocating slots in a buffer, and there are far more effective
>> ways to do that than a full-blown address space manager.
>
> Considering iova allocation efficiency, I think the iova allocator is
> better here. In most cases, we don't even need to hold a spin lock
> during iova allocation.
>
>> If you're going
>> to reuse any infrastructure I'd have expected it to be SWIOTLB rather
>> than the IOVA allocator. Because, y'know, you're *literally implementing
>> a software I/O TLB* ;)
>>
>
> But actually what we can reuse in SWIOTLB is the IOVA allocator.
Huh? Those are completely unrelated and orthogonal things - SWIOTLB does
not use an external allocator (see find_slots()). By SWIOTLB I mean
specifically the library itself, not dma-direct or any of the other
users built around it. The functionality for managing slots in a buffer
and bouncing data in and out can absolutely be reused - that's why users
like the Xen and iommu-dma code *are* reusing it instead of open-coding
their own versions.
> And
> the IOVA management in SWIOTLB is not what we want. For example,
> SWIOTLB allocates and uses contiguous memory for bouncing, which is
> not necessary in VDUSE case.
alloc_iova() allocates a contiguous (in IOVA address) region of space.
In vduse_domain_map_page() you use it to allocate a contiguous region of
space from your bounce buffer. Can you clarify how that is fundamentally
different from allocating a contiguous region of space from a bounce
buffer? Nobody's saying the underlying implementation details of where
the buffer itself comes from can't be tweaked.
> And VDUSE needs coherent mapping which is
> not supported by the SWIOTLB. Besides, the SWIOTLB works in singleton
> mode (designed for platform IOMMU) , but VDUSE is based on on-chip
> IOMMU (supports multiple instances).
That's not entirely true - the IOMMU bounce buffering scheme introduced
in intel-iommu and now moved into the iommu-dma layer was already a step
towards something conceptually similar. It does still rely on stealing
the underlying pages from the global SWIOTLB pool at the moment, but the
bouncing is effectively done in a per-IOMMU-domain context.
The next step is currently queued in linux-next, wherein we can now have
individual per-device SWIOTLB pools. In fact at that point I think you
might actually be able to do your thing without implementing any special
DMA ops at all - you'd need to set up a pool for your "device" with
force_bounce set, then when you mmap() that to userspace, set up
dev->dma_range_map to describe an offset from the physical address of
the buffer to the userspace address, and I think dma-direct would be
tricked into doing the right thing. It's a bit wacky, but it could stand
to save a hell of a lot of bother.
Finally, enhancing SWIOTLB to cope with virtually-mapped buffers that
don't have to be physically contiguous is a future improvement which I
think could benefit various use-cases - indeed it's possibly already on
the table for IOMMU bounce pages - so would probably be welcome in general.
> So I still prefer to reuse the
> IOVA allocator to implement a MMU-based software IOTLB.
If you're dead set on open-coding all the bounce-buffering machinery,
then I'd honestly recommend open-coding a more suitable buffer allocator
as well ;)
Thanks,
Robin.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH v10 01/17] iova: Export alloc_iova_fast() and free_iova_fast()
2021-08-04 15:43 ` Robin Murphy
@ 2021-08-05 12:34 ` Yongji Xie
2021-08-05 13:31 ` Jason Wang
0 siblings, 1 reply; 55+ messages in thread
From: Yongji Xie @ 2021-08-05 12:34 UTC (permalink / raw)
To: Robin Murphy
Cc: kvm, Michael S. Tsirkin, Jason Wang, virtualization,
Christian Brauner, Jonathan Corbet, Matthew Wilcox,
Christoph Hellwig, Dan Carpenter, Stefano Garzarella,
Liu Xiaodong, Joe Perches, Al Viro, Stefan Hajnoczi, songmuchun,
Jens Axboe, He Zhe, Greg KH, Randy Dunlap, linux-kernel, iommu,
bcrl, netdev, linux-fsdevel, Mika Penttilä
On Wed, Aug 4, 2021 at 11:43 PM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2021-08-04 06:02, Yongji Xie wrote:
> > On Tue, Aug 3, 2021 at 6:54 PM Robin Murphy <robin.murphy@arm.com> wrote:
> >>
> >> On 2021-08-03 09:54, Yongji Xie wrote:
> >>> On Tue, Aug 3, 2021 at 3:41 PM Jason Wang <jasowang@redhat.com> wrote:
> >>>>
> >>>>
> >>>> 在 2021/7/29 下午3:34, Xie Yongji 写道:
> >>>>> Export alloc_iova_fast() and free_iova_fast() so that
> >>>>> some modules can use it to improve iova allocation efficiency.
> >>>>
> >>>>
> >>>> It's better to explain why alloc_iova() is not sufficient here.
> >>>>
> >>>
> >>> Fine.
> >>
> >> What I fail to understand from the later patches is what the IOVA domain
> >> actually represents. If the "device" is a userspace process then
> >> logically the "IOVA" would be the userspace address, so presumably
> >> somewhere you're having to translate between this arbitrary address
> >> space and actual usable addresses - if you're worried about efficiency
> >> surely it would be even better to not do that?
> >>
> >
> > Yes, userspace daemon needs to translate the "IOVA" in a DMA
> > descriptor to the VA (from mmap(2)). But this actually doesn't affect
> > performance since it's an identical mapping in most cases.
>
> I'm not familiar with the vhost_iotlb stuff, but it looks suspiciously
> like you're walking yet another tree to make those translations. Even if
> the buffer can be mapped all at once with a fixed offset such that each
> DMA mapping call doesn't need a lookup for each individual "IOVA" - that
> might be what's happening already, but it's a bit hard to follow just
> reading the patches in my mail client - vhost_iotlb_add_range() doesn't
> look like it's super-cheap to call, and you're serialising on a lock for
> that.
>
Yes, that's true. Since the software IOTLB is not used in the VM case,
we need a unified way (vhost_iotlb) to manage the IOVA mapping for
both VM and Container cases.
> My main point, though, is that if you've already got something else
> keeping track of the actual addresses, then the way you're using an
> iova_domain appears to be something you could do with a trivial bitmap
> allocator. That's why I don't buy the efficiency argument. The main
> design points of the IOVA allocator are to manage large address spaces
> while trying to maximise spatial locality to minimise the underlying
> pagetable usage, and allocating with a flexible limit to support
> multiple devices with different addressing capabilities in the same
> address space. If none of those aspects are relevant to the use-case -
> which AFAICS appears to be true here - then as a general-purpose
> resource allocator it's rubbish and has an unreasonably massive memory
> overhead and there are many, many better choices.
>
OK, I get your point. Actually we used the genpool allocator in the
early version. Maybe we can fall back to using it.
> FWIW I've recently started thinking about moving all the caching stuff
> out of iova_domain and into the iommu-dma layer since it's now a giant
> waste of space for all the other current IOVA users.
>
> >> Presumably userspace doesn't have any concern about alignment and the
> >> things we have to worry about for the DMA API in general, so it's pretty
> >> much just allocating slots in a buffer, and there are far more effective
> >> ways to do that than a full-blown address space manager.
> >
> > Considering iova allocation efficiency, I think the iova allocator is
> > better here. In most cases, we don't even need to hold a spin lock
> > during iova allocation.
> >
> >> If you're going
> >> to reuse any infrastructure I'd have expected it to be SWIOTLB rather
> >> than the IOVA allocator. Because, y'know, you're *literally implementing
> >> a software I/O TLB* ;)
> >>
> >
> > But actually what we can reuse in SWIOTLB is the IOVA allocator.
>
> Huh? Those are completely unrelated and orthogonal things - SWIOTLB does
> not use an external allocator (see find_slots()). By SWIOTLB I mean
> specifically the library itself, not dma-direct or any of the other
> users built around it. The functionality for managing slots in a buffer
> and bouncing data in and out can absolutely be reused - that's why users
> like the Xen and iommu-dma code *are* reusing it instead of open-coding
> their own versions.
>
I see. Actually the slots management in SWIOTLB is what I mean by IOVA
allocator.
> > And
> > the IOVA management in SWIOTLB is not what we want. For example,
> > SWIOTLB allocates and uses contiguous memory for bouncing, which is
> > not necessary in VDUSE case.
>
> alloc_iova() allocates a contiguous (in IOVA address) region of space.
> In vduse_domain_map_page() you use it to allocate a contiguous region of
> space from your bounce buffer. Can you clarify how that is fundamentally
> different from allocating a contiguous region of space from a bounce
> buffer? Nobody's saying the underlying implementation details of where
> the buffer itself comes from can't be tweaked.
>
I mean physically contiguous memory here. We can currently allocate
the bounce pages one by one rather than allocating a bunch of
physically contiguous memory at once which is not friendly to a
userspace device.
> > And VDUSE needs coherent mapping which is
> > not supported by the SWIOTLB. Besides, the SWIOTLB works in singleton
> > mode (designed for platform IOMMU) , but VDUSE is based on on-chip
> > IOMMU (supports multiple instances).
> That's not entirely true - the IOMMU bounce buffering scheme introduced
> in intel-iommu and now moved into the iommu-dma layer was already a step
> towards something conceptually similar. It does still rely on stealing
> the underlying pages from the global SWIOTLB pool at the moment, but the
> bouncing is effectively done in a per-IOMMU-domain context.
>
> The next step is currently queued in linux-next, wherein we can now have
> individual per-device SWIOTLB pools. In fact at that point I think you
> might actually be able to do your thing without implementing any special
> DMA ops at all - you'd need to set up a pool for your "device" with
> force_bounce set, then when you mmap() that to userspace, set up
> dev->dma_range_map to describe an offset from the physical address of
> the buffer to the userspace address, and I think dma-direct would be
> tricked into doing the right thing. It's a bit wacky, but it could stand
> to save a hell of a lot of bother.
>
Cool! I missed this work, sorry. But it looks like its current version
can't meet our needs (e.g. avoid using physically contiguous memory).
So I'd like to consider it as a follow-up optimization and use a
general IOVA allocator in this initial version. The IOVA allocator
would be still needed for coherent mapping
(vduse_domain_alloc_coherent() and vduse_domain_free_coherent()) after
we reuse the SWIOTLB.
> Finally, enhancing SWIOTLB to cope with virtually-mapped buffers that
> don't have to be physically contiguous is a future improvement which I
> think could benefit various use-cases - indeed it's possibly already on
> the table for IOMMU bounce pages - so would probably be welcome in general.
>
Yes, it's indeed needed by VDUSE. But I'm not sure if it would be
needed by other drivers. Looks like we need swiotlb_tbl_map_single()
to return a virtual address and introduce some way to let the caller
do some translation between VA to PA.
Thanks,
Yongji
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH v10 01/17] iova: Export alloc_iova_fast() and free_iova_fast()
2021-08-05 12:34 ` Yongji Xie
@ 2021-08-05 13:31 ` Jason Wang
2021-08-09 5:56 ` Yongji Xie
0 siblings, 1 reply; 55+ messages in thread
From: Jason Wang @ 2021-08-05 13:31 UTC (permalink / raw)
To: Yongji Xie, Robin Murphy
Cc: kvm, Michael S. Tsirkin, virtualization, Christian Brauner,
Jonathan Corbet, Matthew Wilcox, Christoph Hellwig,
Dan Carpenter, Stefano Garzarella, Liu Xiaodong, Joe Perches,
Al Viro, Stefan Hajnoczi, songmuchun, Jens Axboe, He Zhe,
Greg KH, Randy Dunlap, linux-kernel, iommu, bcrl, netdev,
linux-fsdevel, Mika Penttilä
在 2021/8/5 下午8:34, Yongji Xie 写道:
>> My main point, though, is that if you've already got something else
>> keeping track of the actual addresses, then the way you're using an
>> iova_domain appears to be something you could do with a trivial bitmap
>> allocator. That's why I don't buy the efficiency argument. The main
>> design points of the IOVA allocator are to manage large address spaces
>> while trying to maximise spatial locality to minimise the underlying
>> pagetable usage, and allocating with a flexible limit to support
>> multiple devices with different addressing capabilities in the same
>> address space. If none of those aspects are relevant to the use-case -
>> which AFAICS appears to be true here - then as a general-purpose
>> resource allocator it's rubbish and has an unreasonably massive memory
>> overhead and there are many, many better choices.
>>
> OK, I get your point. Actually we used the genpool allocator in the
> early version. Maybe we can fall back to using it.
I think maybe you can share some perf numbers to see how much
alloc_iova_fast() can help.
Thanks
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH v10 01/17] iova: Export alloc_iova_fast() and free_iova_fast()
2021-08-05 13:31 ` Jason Wang
@ 2021-08-09 5:56 ` Yongji Xie
2021-08-10 3:02 ` Jason Wang
0 siblings, 1 reply; 55+ messages in thread
From: Yongji Xie @ 2021-08-09 5:56 UTC (permalink / raw)
To: Jason Wang, Robin Murphy
Cc: kvm, Michael S. Tsirkin, virtualization, Christian Brauner,
Jonathan Corbet, Matthew Wilcox, Christoph Hellwig,
Dan Carpenter, Stefano Garzarella, Liu Xiaodong, Joe Perches,
Al Viro, Stefan Hajnoczi, songmuchun, Jens Axboe, He Zhe,
Greg KH, Randy Dunlap, linux-kernel, iommu, bcrl, netdev,
linux-fsdevel, Mika Penttilä
On Thu, Aug 5, 2021 at 9:31 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/8/5 下午8:34, Yongji Xie 写道:
> >> My main point, though, is that if you've already got something else
> >> keeping track of the actual addresses, then the way you're using an
> >> iova_domain appears to be something you could do with a trivial bitmap
> >> allocator. That's why I don't buy the efficiency argument. The main
> >> design points of the IOVA allocator are to manage large address spaces
> >> while trying to maximise spatial locality to minimise the underlying
> >> pagetable usage, and allocating with a flexible limit to support
> >> multiple devices with different addressing capabilities in the same
> >> address space. If none of those aspects are relevant to the use-case -
> >> which AFAICS appears to be true here - then as a general-purpose
> >> resource allocator it's rubbish and has an unreasonably massive memory
> >> overhead and there are many, many better choices.
> >>
> > OK, I get your point. Actually we used the genpool allocator in the
> > early version. Maybe we can fall back to using it.
>
>
> I think maybe you can share some perf numbers to see how much
> alloc_iova_fast() can help.
>
I did some fio tests[1] with a ram-backend vduse block device[2].
Following are some performance data:
numjobs=1 numjobs=2 numjobs=4 numjobs=8
iova_alloc_fast 145k iops 265k iops 514k iops 758k iops
iova_alloc 137k iops 170k iops 128k iops 113k iops
gen_pool_alloc 143k iops 270k iops 458k iops 521k iops
The iova_alloc_fast() has the best performance since we always hit the
per-cpu cache. Regardless of the per-cpu cache, the genpool allocator
should be better than the iova allocator.
[1] fio jobfile:
[global]
rw=randread
direct=1
ioengine=libaio
iodepth=16
time_based=1
runtime=60s
group_reporting
bs=4k
filename=/dev/vda
[job]
numjobs=..
[2] $ qemu-storage-daemon \
--chardev socket,id=charmonitor,path=/tmp/qmp.sock,server,nowait \
--monitor chardev=charmonitor \
--blockdev
driver=host_device,cache.direct=on,aio=native,filename=/dev/nullb0,node-name=disk0
\
--export type=vduse-blk,id=test,node-name=disk0,writable=on,name=vduse-null,num-queues=16,queue-size=128
The qemu-storage-daemon can be builded based on the repo:
https://github.com/bytedance/qemu/tree/vduse-test.
Thanks,
Yongji
^ permalink raw reply [flat|nested] 55+ messages in thread* Re: [PATCH v10 01/17] iova: Export alloc_iova_fast() and free_iova_fast()
2021-08-09 5:56 ` Yongji Xie
@ 2021-08-10 3:02 ` Jason Wang
2021-08-10 7:43 ` Yongji Xie
0 siblings, 1 reply; 55+ messages in thread
From: Jason Wang @ 2021-08-10 3:02 UTC (permalink / raw)
To: Yongji Xie, Robin Murphy
Cc: kvm, Michael S. Tsirkin, virtualization, Christian Brauner,
Jonathan Corbet, Matthew Wilcox, Christoph Hellwig,
Dan Carpenter, Stefano Garzarella, Liu Xiaodong, Joe Perches,
Al Viro, Stefan Hajnoczi, songmuchun, Jens Axboe, He Zhe,
Greg KH, Randy Dunlap, linux-kernel, iommu, bcrl, netdev,
linux-fsdevel, Mika Penttilä
在 2021/8/9 下午1:56, Yongji Xie 写道:
> On Thu, Aug 5, 2021 at 9:31 PM Jason Wang <jasowang@redhat.com> wrote:
>>
>> 在 2021/8/5 下午8:34, Yongji Xie 写道:
>>>> My main point, though, is that if you've already got something else
>>>> keeping track of the actual addresses, then the way you're using an
>>>> iova_domain appears to be something you could do with a trivial bitmap
>>>> allocator. That's why I don't buy the efficiency argument. The main
>>>> design points of the IOVA allocator are to manage large address spaces
>>>> while trying to maximise spatial locality to minimise the underlying
>>>> pagetable usage, and allocating with a flexible limit to support
>>>> multiple devices with different addressing capabilities in the same
>>>> address space. If none of those aspects are relevant to the use-case -
>>>> which AFAICS appears to be true here - then as a general-purpose
>>>> resource allocator it's rubbish and has an unreasonably massive memory
>>>> overhead and there are many, many better choices.
>>>>
>>> OK, I get your point. Actually we used the genpool allocator in the
>>> early version. Maybe we can fall back to using it.
>>
>> I think maybe you can share some perf numbers to see how much
>> alloc_iova_fast() can help.
>>
> I did some fio tests[1] with a ram-backend vduse block device[2].
>
> Following are some performance data:
>
> numjobs=1 numjobs=2 numjobs=4 numjobs=8
> iova_alloc_fast 145k iops 265k iops 514k iops 758k iops
>
> iova_alloc 137k iops 170k iops 128k iops 113k iops
>
> gen_pool_alloc 143k iops 270k iops 458k iops 521k iops
>
> The iova_alloc_fast() has the best performance since we always hit the
> per-cpu cache. Regardless of the per-cpu cache, the genpool allocator
> should be better than the iova allocator.
I think we see convincing numbers for using iova_alloc_fast() than the
gen_poll_alloc() (45% improvement on job=8).
Thanks
>
> [1] fio jobfile:
>
> [global]
> rw=randread
> direct=1
> ioengine=libaio
> iodepth=16
> time_based=1
> runtime=60s
> group_reporting
> bs=4k
> filename=/dev/vda
> [job]
> numjobs=..
>
> [2] $ qemu-storage-daemon \
> --chardev socket,id=charmonitor,path=/tmp/qmp.sock,server,nowait \
> --monitor chardev=charmonitor \
> --blockdev
> driver=host_device,cache.direct=on,aio=native,filename=/dev/nullb0,node-name=disk0
> \
> --export type=vduse-blk,id=test,node-name=disk0,writable=on,name=vduse-null,num-queues=16,queue-size=128
>
> The qemu-storage-daemon can be builded based on the repo:
> https://github.com/bytedance/qemu/tree/vduse-test.
>
> Thanks,
> Yongji
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH v10 01/17] iova: Export alloc_iova_fast() and free_iova_fast()
2021-08-10 3:02 ` Jason Wang
@ 2021-08-10 7:43 ` Yongji Xie
0 siblings, 0 replies; 55+ messages in thread
From: Yongji Xie @ 2021-08-10 7:43 UTC (permalink / raw)
To: Jason Wang, Robin Murphy
Cc: kvm, Michael S. Tsirkin, virtualization, Christian Brauner,
Jonathan Corbet, Matthew Wilcox, Christoph Hellwig,
Dan Carpenter, Stefano Garzarella, Liu Xiaodong, Joe Perches,
Al Viro, Stefan Hajnoczi, songmuchun, Jens Axboe, He Zhe,
Greg KH, Randy Dunlap, linux-kernel, iommu, bcrl, netdev,
linux-fsdevel, Mika Penttilä
On Tue, Aug 10, 2021 at 11:02 AM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/8/9 下午1:56, Yongji Xie 写道:
> > On Thu, Aug 5, 2021 at 9:31 PM Jason Wang <jasowang@redhat.com> wrote:
> >>
> >> 在 2021/8/5 下午8:34, Yongji Xie 写道:
> >>>> My main point, though, is that if you've already got something else
> >>>> keeping track of the actual addresses, then the way you're using an
> >>>> iova_domain appears to be something you could do with a trivial bitmap
> >>>> allocator. That's why I don't buy the efficiency argument. The main
> >>>> design points of the IOVA allocator are to manage large address spaces
> >>>> while trying to maximise spatial locality to minimise the underlying
> >>>> pagetable usage, and allocating with a flexible limit to support
> >>>> multiple devices with different addressing capabilities in the same
> >>>> address space. If none of those aspects are relevant to the use-case -
> >>>> which AFAICS appears to be true here - then as a general-purpose
> >>>> resource allocator it's rubbish and has an unreasonably massive memory
> >>>> overhead and there are many, many better choices.
> >>>>
> >>> OK, I get your point. Actually we used the genpool allocator in the
> >>> early version. Maybe we can fall back to using it.
> >>
> >> I think maybe you can share some perf numbers to see how much
> >> alloc_iova_fast() can help.
> >>
> > I did some fio tests[1] with a ram-backend vduse block device[2].
> >
> > Following are some performance data:
> >
> > numjobs=1 numjobs=2 numjobs=4 numjobs=8
> > iova_alloc_fast 145k iops 265k iops 514k iops 758k iops
> >
> > iova_alloc 137k iops 170k iops 128k iops 113k iops
> >
> > gen_pool_alloc 143k iops 270k iops 458k iops 521k iops
> >
> > The iova_alloc_fast() has the best performance since we always hit the
> > per-cpu cache. Regardless of the per-cpu cache, the genpool allocator
> > should be better than the iova allocator.
>
>
> I think we see convincing numbers for using iova_alloc_fast() than the
> gen_poll_alloc() (45% improvement on job=8).
>
Yes, so alloc_iova_fast() still seems to be the best choice based on
performance considerations.
Hi Robin, any comments?
Thanks,
Yongji
^ permalink raw reply [flat|nested] 55+ messages in thread
* [PATCH v10 02/17] file: Export receive_fd() to modules
2021-07-29 7:34 [PATCH v10 00/17] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
2021-07-29 7:34 ` [PATCH v10 01/17] iova: Export alloc_iova_fast() and free_iova_fast() Xie Yongji
@ 2021-07-29 7:34 ` Xie Yongji
2021-08-03 7:45 ` Jason Wang
2021-07-29 7:34 ` [PATCH v10 03/17] vdpa: Fix code indentation Xie Yongji
` (14 subsequent siblings)
16 siblings, 1 reply; 55+ messages in thread
From: Xie Yongji @ 2021-07-29 7:34 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu, joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
Export receive_fd() so that some modules can use
it to pass file descriptor between processes without
missing any security stuffs.
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
---
fs/file.c | 6 ++++++
include/linux/file.h | 7 +++----
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/fs/file.c b/fs/file.c
index 86dc9956af32..210e540672aa 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -1134,6 +1134,12 @@ int receive_fd_replace(int new_fd, struct file *file, unsigned int o_flags)
return new_fd;
}
+int receive_fd(struct file *file, unsigned int o_flags)
+{
+ return __receive_fd(file, NULL, o_flags);
+}
+EXPORT_SYMBOL_GPL(receive_fd);
+
static int ksys_dup3(unsigned int oldfd, unsigned int newfd, int flags)
{
int err = -EBADF;
diff --git a/include/linux/file.h b/include/linux/file.h
index 2de2e4613d7b..51e830b4fe3a 100644
--- a/include/linux/file.h
+++ b/include/linux/file.h
@@ -94,6 +94,9 @@ extern void fd_install(unsigned int fd, struct file *file);
extern int __receive_fd(struct file *file, int __user *ufd,
unsigned int o_flags);
+
+extern int receive_fd(struct file *file, unsigned int o_flags);
+
static inline int receive_fd_user(struct file *file, int __user *ufd,
unsigned int o_flags)
{
@@ -101,10 +104,6 @@ static inline int receive_fd_user(struct file *file, int __user *ufd,
return -EFAULT;
return __receive_fd(file, ufd, o_flags);
}
-static inline int receive_fd(struct file *file, unsigned int o_flags)
-{
- return __receive_fd(file, NULL, o_flags);
-}
int receive_fd_replace(int new_fd, struct file *file, unsigned int o_flags);
extern void flush_delayed_fput(void);
--
2.11.0
^ permalink raw reply related [flat|nested] 55+ messages in thread* Re: [PATCH v10 02/17] file: Export receive_fd() to modules
2021-07-29 7:34 ` [PATCH v10 02/17] file: Export receive_fd() to modules Xie Yongji
@ 2021-08-03 7:45 ` Jason Wang
2021-08-03 9:01 ` Yongji Xie
0 siblings, 1 reply; 55+ messages in thread
From: Jason Wang @ 2021-08-03 7:45 UTC (permalink / raw)
To: Xie Yongji, mst, stefanha, sgarzare, parav, hch,
christian.brauner, rdunlap, willy, viro, axboe, bcrl, corbet,
mika.penttila, dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu,
joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
在 2021/7/29 下午3:34, Xie Yongji 写道:
> Export receive_fd() so that some modules can use
> it to pass file descriptor between processes without
> missing any security stuffs.
>
> Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> ---
> fs/file.c | 6 ++++++
> include/linux/file.h | 7 +++----
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/fs/file.c b/fs/file.c
> index 86dc9956af32..210e540672aa 100644
> --- a/fs/file.c
> +++ b/fs/file.c
> @@ -1134,6 +1134,12 @@ int receive_fd_replace(int new_fd, struct file *file, unsigned int o_flags)
> return new_fd;
> }
>
> +int receive_fd(struct file *file, unsigned int o_flags)
> +{
> + return __receive_fd(file, NULL, o_flags);
Any reason that receive_fd_user() can live in the file.h?
Thanks
> +}
> +EXPORT_SYMBOL_GPL(receive_fd);
> +
> static int ksys_dup3(unsigned int oldfd, unsigned int newfd, int flags)
> {
> int err = -EBADF;
> diff --git a/include/linux/file.h b/include/linux/file.h
> index 2de2e4613d7b..51e830b4fe3a 100644
> --- a/include/linux/file.h
> +++ b/include/linux/file.h
> @@ -94,6 +94,9 @@ extern void fd_install(unsigned int fd, struct file *file);
>
> extern int __receive_fd(struct file *file, int __user *ufd,
> unsigned int o_flags);
> +
> +extern int receive_fd(struct file *file, unsigned int o_flags);
> +
> static inline int receive_fd_user(struct file *file, int __user *ufd,
> unsigned int o_flags)
> {
> @@ -101,10 +104,6 @@ static inline int receive_fd_user(struct file *file, int __user *ufd,
> return -EFAULT;
> return __receive_fd(file, ufd, o_flags);
> }
> -static inline int receive_fd(struct file *file, unsigned int o_flags)
> -{
> - return __receive_fd(file, NULL, o_flags);
> -}
> int receive_fd_replace(int new_fd, struct file *file, unsigned int o_flags);
>
> extern void flush_delayed_fput(void);
^ permalink raw reply [flat|nested] 55+ messages in thread* Re: [PATCH v10 02/17] file: Export receive_fd() to modules
2021-08-03 7:45 ` Jason Wang
@ 2021-08-03 9:01 ` Yongji Xie
2021-08-04 8:27 ` Jason Wang
0 siblings, 1 reply; 55+ messages in thread
From: Yongji Xie @ 2021-08-03 9:01 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, Greg KH, He Zhe, Liu Xiaodong, Joe Perches,
songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
On Tue, Aug 3, 2021 at 3:46 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/7/29 下午3:34, Xie Yongji 写道:
> > Export receive_fd() so that some modules can use
> > it to pass file descriptor between processes without
> > missing any security stuffs.
> >
> > Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> > ---
> > fs/file.c | 6 ++++++
> > include/linux/file.h | 7 +++----
> > 2 files changed, 9 insertions(+), 4 deletions(-)
> >
> > diff --git a/fs/file.c b/fs/file.c
> > index 86dc9956af32..210e540672aa 100644
> > --- a/fs/file.c
> > +++ b/fs/file.c
> > @@ -1134,6 +1134,12 @@ int receive_fd_replace(int new_fd, struct file *file, unsigned int o_flags)
> > return new_fd;
> > }
> >
> > +int receive_fd(struct file *file, unsigned int o_flags)
> > +{
> > + return __receive_fd(file, NULL, o_flags);
>
>
> Any reason that receive_fd_user() can live in the file.h?
>
Since no modules use it.
Thanks,
Yongji
^ permalink raw reply [flat|nested] 55+ messages in thread* Re: [PATCH v10 02/17] file: Export receive_fd() to modules
2021-08-03 9:01 ` Yongji Xie
@ 2021-08-04 8:27 ` Jason Wang
0 siblings, 0 replies; 55+ messages in thread
From: Jason Wang @ 2021-08-04 8:27 UTC (permalink / raw)
To: Yongji Xie
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, Greg KH, He Zhe, Liu Xiaodong, Joe Perches,
songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
在 2021/8/3 下午5:01, Yongji Xie 写道:
> On Tue, Aug 3, 2021 at 3:46 PM Jason Wang <jasowang@redhat.com> wrote:
>>
>> 在 2021/7/29 下午3:34, Xie Yongji 写道:
>>> Export receive_fd() so that some modules can use
>>> it to pass file descriptor between processes without
>>> missing any security stuffs.
>>>
>>> Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
>>> ---
>>> fs/file.c | 6 ++++++
>>> include/linux/file.h | 7 +++----
>>> 2 files changed, 9 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/fs/file.c b/fs/file.c
>>> index 86dc9956af32..210e540672aa 100644
>>> --- a/fs/file.c
>>> +++ b/fs/file.c
>>> @@ -1134,6 +1134,12 @@ int receive_fd_replace(int new_fd, struct file *file, unsigned int o_flags)
>>> return new_fd;
>>> }
>>>
>>> +int receive_fd(struct file *file, unsigned int o_flags)
>>> +{
>>> + return __receive_fd(file, NULL, o_flags);
>>
>> Any reason that receive_fd_user() can live in the file.h?
>>
> Since no modules use it.
>
> Thanks,
> Yongji
Ok.
Acked-by: Jason Wang <jasowang@redhat.com>
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* [PATCH v10 03/17] vdpa: Fix code indentation
2021-07-29 7:34 [PATCH v10 00/17] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
2021-07-29 7:34 ` [PATCH v10 01/17] iova: Export alloc_iova_fast() and free_iova_fast() Xie Yongji
2021-07-29 7:34 ` [PATCH v10 02/17] file: Export receive_fd() to modules Xie Yongji
@ 2021-07-29 7:34 ` Xie Yongji
2021-08-03 7:50 ` Jason Wang
2021-07-29 7:34 ` [PATCH v10 04/17] vdpa: Fail the vdpa_reset() if fail to set device status to zero Xie Yongji
` (13 subsequent siblings)
16 siblings, 1 reply; 55+ messages in thread
From: Xie Yongji @ 2021-07-29 7:34 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu, joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
Use tabs to indent the code instead of spaces.
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
---
include/linux/vdpa.h | 29 ++++++++++++++---------------
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
index 7c49bc5a2b71..406d53a606ac 100644
--- a/include/linux/vdpa.h
+++ b/include/linux/vdpa.h
@@ -43,17 +43,17 @@ struct vdpa_vq_state_split {
* @last_used_idx: used index
*/
struct vdpa_vq_state_packed {
- u16 last_avail_counter:1;
- u16 last_avail_idx:15;
- u16 last_used_counter:1;
- u16 last_used_idx:15;
+ u16 last_avail_counter:1;
+ u16 last_avail_idx:15;
+ u16 last_used_counter:1;
+ u16 last_used_idx:15;
};
struct vdpa_vq_state {
- union {
- struct vdpa_vq_state_split split;
- struct vdpa_vq_state_packed packed;
- };
+ union {
+ struct vdpa_vq_state_split split;
+ struct vdpa_vq_state_packed packed;
+ };
};
struct vdpa_mgmt_dev;
@@ -131,7 +131,7 @@ struct vdpa_iova_range {
* @vdev: vdpa device
* @idx: virtqueue index
* @state: pointer to returned state (last_avail_idx)
- * @get_vq_notification: Get the notification area for a virtqueue
+ * @get_vq_notification: Get the notification area for a virtqueue
* @vdev: vdpa device
* @idx: virtqueue index
* Returns the notifcation area
@@ -342,25 +342,24 @@ static inline struct device *vdpa_get_dma_dev(struct vdpa_device *vdev)
static inline void vdpa_reset(struct vdpa_device *vdev)
{
- const struct vdpa_config_ops *ops = vdev->config;
+ const struct vdpa_config_ops *ops = vdev->config;
vdev->features_valid = false;
- ops->set_status(vdev, 0);
+ ops->set_status(vdev, 0);
}
static inline int vdpa_set_features(struct vdpa_device *vdev, u64 features)
{
- const struct vdpa_config_ops *ops = vdev->config;
+ const struct vdpa_config_ops *ops = vdev->config;
vdev->features_valid = true;
- return ops->set_features(vdev, features);
+ return ops->set_features(vdev, features);
}
-
static inline void vdpa_get_config(struct vdpa_device *vdev, unsigned offset,
void *buf, unsigned int len)
{
- const struct vdpa_config_ops *ops = vdev->config;
+ const struct vdpa_config_ops *ops = vdev->config;
/*
* Config accesses aren't supposed to trigger before features are set.
--
2.11.0
^ permalink raw reply related [flat|nested] 55+ messages in thread* Re: [PATCH v10 03/17] vdpa: Fix code indentation
2021-07-29 7:34 ` [PATCH v10 03/17] vdpa: Fix code indentation Xie Yongji
@ 2021-08-03 7:50 ` Jason Wang
2021-08-03 9:13 ` Yongji Xie
0 siblings, 1 reply; 55+ messages in thread
From: Jason Wang @ 2021-08-03 7:50 UTC (permalink / raw)
To: Xie Yongji, mst, stefanha, sgarzare, parav, hch,
christian.brauner, rdunlap, willy, viro, axboe, bcrl, corbet,
mika.penttila, dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu,
joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
在 2021/7/29 下午3:34, Xie Yongji 写道:
> Use tabs to indent the code instead of spaces.
>
> Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> ---
> include/linux/vdpa.h | 29 ++++++++++++++---------------
> 1 file changed, 14 insertions(+), 15 deletions(-)
It looks to me not all the warnings are addressed.
Or did you silent checkpatch.pl -f?
Thanks
>
> diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
> index 7c49bc5a2b71..406d53a606ac 100644
> --- a/include/linux/vdpa.h
> +++ b/include/linux/vdpa.h
> @@ -43,17 +43,17 @@ struct vdpa_vq_state_split {
> * @last_used_idx: used index
> */
> struct vdpa_vq_state_packed {
> - u16 last_avail_counter:1;
> - u16 last_avail_idx:15;
> - u16 last_used_counter:1;
> - u16 last_used_idx:15;
> + u16 last_avail_counter:1;
> + u16 last_avail_idx:15;
> + u16 last_used_counter:1;
> + u16 last_used_idx:15;
> };
>
> struct vdpa_vq_state {
> - union {
> - struct vdpa_vq_state_split split;
> - struct vdpa_vq_state_packed packed;
> - };
> + union {
> + struct vdpa_vq_state_split split;
> + struct vdpa_vq_state_packed packed;
> + };
> };
>
> struct vdpa_mgmt_dev;
> @@ -131,7 +131,7 @@ struct vdpa_iova_range {
> * @vdev: vdpa device
> * @idx: virtqueue index
> * @state: pointer to returned state (last_avail_idx)
> - * @get_vq_notification: Get the notification area for a virtqueue
> + * @get_vq_notification: Get the notification area for a virtqueue
> * @vdev: vdpa device
> * @idx: virtqueue index
> * Returns the notifcation area
> @@ -342,25 +342,24 @@ static inline struct device *vdpa_get_dma_dev(struct vdpa_device *vdev)
>
> static inline void vdpa_reset(struct vdpa_device *vdev)
> {
> - const struct vdpa_config_ops *ops = vdev->config;
> + const struct vdpa_config_ops *ops = vdev->config;
>
> vdev->features_valid = false;
> - ops->set_status(vdev, 0);
> + ops->set_status(vdev, 0);
> }
>
> static inline int vdpa_set_features(struct vdpa_device *vdev, u64 features)
> {
> - const struct vdpa_config_ops *ops = vdev->config;
> + const struct vdpa_config_ops *ops = vdev->config;
>
> vdev->features_valid = true;
> - return ops->set_features(vdev, features);
> + return ops->set_features(vdev, features);
> }
>
> -
> static inline void vdpa_get_config(struct vdpa_device *vdev, unsigned offset,
> void *buf, unsigned int len)
> {
> - const struct vdpa_config_ops *ops = vdev->config;
> + const struct vdpa_config_ops *ops = vdev->config;
>
> /*
> * Config accesses aren't supposed to trigger before features are set.
^ permalink raw reply [flat|nested] 55+ messages in thread* Re: [PATCH v10 03/17] vdpa: Fix code indentation
2021-08-03 7:50 ` Jason Wang
@ 2021-08-03 9:13 ` Yongji Xie
0 siblings, 0 replies; 55+ messages in thread
From: Yongji Xie @ 2021-08-03 9:13 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, Greg KH, He Zhe, Liu Xiaodong, Joe Perches,
songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
On Tue, Aug 3, 2021 at 3:51 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/7/29 下午3:34, Xie Yongji 写道:
> > Use tabs to indent the code instead of spaces.
> >
> > Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> > ---
> > include/linux/vdpa.h | 29 ++++++++++++++---------------
> > 1 file changed, 14 insertions(+), 15 deletions(-)
>
>
> It looks to me not all the warnings are addressed.
>
> Or did you silent checkpatch.pl -f?
>
This patch only fixes the code indent issue. I will address all
warnings in the next version.
Thanks,
Yongji
^ permalink raw reply [flat|nested] 55+ messages in thread
* [PATCH v10 04/17] vdpa: Fail the vdpa_reset() if fail to set device status to zero
2021-07-29 7:34 [PATCH v10 00/17] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (2 preceding siblings ...)
2021-07-29 7:34 ` [PATCH v10 03/17] vdpa: Fix code indentation Xie Yongji
@ 2021-07-29 7:34 ` Xie Yongji
2021-08-03 7:58 ` Jason Wang
2021-07-29 7:34 ` [PATCH v10 05/17] vhost-vdpa: Fail the vhost_vdpa_set_status() on reset failure Xie Yongji
` (12 subsequent siblings)
16 siblings, 1 reply; 55+ messages in thread
From: Xie Yongji @ 2021-07-29 7:34 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu, joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
Re-read the device status to ensure it's set to zero during
resetting. Otherwise, fail the vdpa_reset() after timeout.
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
---
include/linux/vdpa.h | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
index 406d53a606ac..d1a80ef05089 100644
--- a/include/linux/vdpa.h
+++ b/include/linux/vdpa.h
@@ -6,6 +6,7 @@
#include <linux/device.h>
#include <linux/interrupt.h>
#include <linux/vhost_iotlb.h>
+#include <linux/delay.h>
/**
* struct vdpa_calllback - vDPA callback definition.
@@ -340,12 +341,24 @@ static inline struct device *vdpa_get_dma_dev(struct vdpa_device *vdev)
return vdev->dma_dev;
}
-static inline void vdpa_reset(struct vdpa_device *vdev)
+#define VDPA_RESET_TIMEOUT_MS 1000
+
+static inline int vdpa_reset(struct vdpa_device *vdev)
{
const struct vdpa_config_ops *ops = vdev->config;
+ int timeout = 0;
vdev->features_valid = false;
ops->set_status(vdev, 0);
+ while (ops->get_status(vdev)) {
+ timeout += 20;
+ if (timeout > VDPA_RESET_TIMEOUT_MS)
+ return -EIO;
+
+ msleep(20);
+ }
+
+ return 0;
}
static inline int vdpa_set_features(struct vdpa_device *vdev, u64 features)
--
2.11.0
^ permalink raw reply related [flat|nested] 55+ messages in thread* Re: [PATCH v10 04/17] vdpa: Fail the vdpa_reset() if fail to set device status to zero
2021-07-29 7:34 ` [PATCH v10 04/17] vdpa: Fail the vdpa_reset() if fail to set device status to zero Xie Yongji
@ 2021-08-03 7:58 ` Jason Wang
2021-08-03 9:31 ` Yongji Xie
0 siblings, 1 reply; 55+ messages in thread
From: Jason Wang @ 2021-08-03 7:58 UTC (permalink / raw)
To: Xie Yongji, mst, stefanha, sgarzare, parav, hch,
christian.brauner, rdunlap, willy, viro, axboe, bcrl, corbet,
mika.penttila, dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu,
joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
在 2021/7/29 下午3:34, Xie Yongji 写道:
> Re-read the device status to ensure it's set to zero during
> resetting. Otherwise, fail the vdpa_reset() after timeout.
>
> Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> ---
> include/linux/vdpa.h | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
> index 406d53a606ac..d1a80ef05089 100644
> --- a/include/linux/vdpa.h
> +++ b/include/linux/vdpa.h
> @@ -6,6 +6,7 @@
> #include <linux/device.h>
> #include <linux/interrupt.h>
> #include <linux/vhost_iotlb.h>
> +#include <linux/delay.h>
>
> /**
> * struct vdpa_calllback - vDPA callback definition.
> @@ -340,12 +341,24 @@ static inline struct device *vdpa_get_dma_dev(struct vdpa_device *vdev)
> return vdev->dma_dev;
> }
>
> -static inline void vdpa_reset(struct vdpa_device *vdev)
> +#define VDPA_RESET_TIMEOUT_MS 1000
> +
> +static inline int vdpa_reset(struct vdpa_device *vdev)
> {
> const struct vdpa_config_ops *ops = vdev->config;
> + int timeout = 0;
>
> vdev->features_valid = false;
> ops->set_status(vdev, 0);
> + while (ops->get_status(vdev)) {
> + timeout += 20;
> + if (timeout > VDPA_RESET_TIMEOUT_MS)
> + return -EIO;
> +
> + msleep(20);
> + }
I wonder if it's better to do this in the vDPA parent?
Thanks
> +
> + return 0;
> }
>
> static inline int vdpa_set_features(struct vdpa_device *vdev, u64 features)
^ permalink raw reply [flat|nested] 55+ messages in thread* Re: [PATCH v10 04/17] vdpa: Fail the vdpa_reset() if fail to set device status to zero
2021-08-03 7:58 ` Jason Wang
@ 2021-08-03 9:31 ` Yongji Xie
2021-08-04 8:30 ` Jason Wang
0 siblings, 1 reply; 55+ messages in thread
From: Yongji Xie @ 2021-08-03 9:31 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, Greg KH, He Zhe, Liu Xiaodong, Joe Perches,
songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
On Tue, Aug 3, 2021 at 3:58 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/7/29 下午3:34, Xie Yongji 写道:
> > Re-read the device status to ensure it's set to zero during
> > resetting. Otherwise, fail the vdpa_reset() after timeout.
> >
> > Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> > ---
> > include/linux/vdpa.h | 15 ++++++++++++++-
> > 1 file changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
> > index 406d53a606ac..d1a80ef05089 100644
> > --- a/include/linux/vdpa.h
> > +++ b/include/linux/vdpa.h
> > @@ -6,6 +6,7 @@
> > #include <linux/device.h>
> > #include <linux/interrupt.h>
> > #include <linux/vhost_iotlb.h>
> > +#include <linux/delay.h>
> >
> > /**
> > * struct vdpa_calllback - vDPA callback definition.
> > @@ -340,12 +341,24 @@ static inline struct device *vdpa_get_dma_dev(struct vdpa_device *vdev)
> > return vdev->dma_dev;
> > }
> >
> > -static inline void vdpa_reset(struct vdpa_device *vdev)
> > +#define VDPA_RESET_TIMEOUT_MS 1000
> > +
> > +static inline int vdpa_reset(struct vdpa_device *vdev)
> > {
> > const struct vdpa_config_ops *ops = vdev->config;
> > + int timeout = 0;
> >
> > vdev->features_valid = false;
> > ops->set_status(vdev, 0);
> > + while (ops->get_status(vdev)) {
> > + timeout += 20;
> > + if (timeout > VDPA_RESET_TIMEOUT_MS)
> > + return -EIO;
> > +
> > + msleep(20);
> > + }
>
>
> I wonder if it's better to do this in the vDPA parent?
>
> Thanks
>
Sorry, I didn't get you here. Do you mean vDPA parent driver (e.g.
VDUSE)? Actually I didn't find any other place where I can do
set_status() and get_status().
Thanks,
Yongji
^ permalink raw reply [flat|nested] 55+ messages in thread* Re: [PATCH v10 04/17] vdpa: Fail the vdpa_reset() if fail to set device status to zero
2021-08-03 9:31 ` Yongji Xie
@ 2021-08-04 8:30 ` Jason Wang
0 siblings, 0 replies; 55+ messages in thread
From: Jason Wang @ 2021-08-04 8:30 UTC (permalink / raw)
To: Yongji Xie
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, Greg KH, He Zhe, Liu Xiaodong, Joe Perches,
songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
在 2021/8/3 下午5:31, Yongji Xie 写道:
> On Tue, Aug 3, 2021 at 3:58 PM Jason Wang <jasowang@redhat.com> wrote:
>>
>> 在 2021/7/29 下午3:34, Xie Yongji 写道:
>>> Re-read the device status to ensure it's set to zero during
>>> resetting. Otherwise, fail the vdpa_reset() after timeout.
>>>
>>> Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
>>> ---
>>> include/linux/vdpa.h | 15 ++++++++++++++-
>>> 1 file changed, 14 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
>>> index 406d53a606ac..d1a80ef05089 100644
>>> --- a/include/linux/vdpa.h
>>> +++ b/include/linux/vdpa.h
>>> @@ -6,6 +6,7 @@
>>> #include <linux/device.h>
>>> #include <linux/interrupt.h>
>>> #include <linux/vhost_iotlb.h>
>>> +#include <linux/delay.h>
>>>
>>> /**
>>> * struct vdpa_calllback - vDPA callback definition.
>>> @@ -340,12 +341,24 @@ static inline struct device *vdpa_get_dma_dev(struct vdpa_device *vdev)
>>> return vdev->dma_dev;
>>> }
>>>
>>> -static inline void vdpa_reset(struct vdpa_device *vdev)
>>> +#define VDPA_RESET_TIMEOUT_MS 1000
>>> +
>>> +static inline int vdpa_reset(struct vdpa_device *vdev)
>>> {
>>> const struct vdpa_config_ops *ops = vdev->config;
>>> + int timeout = 0;
>>>
>>> vdev->features_valid = false;
>>> ops->set_status(vdev, 0);
>>> + while (ops->get_status(vdev)) {
>>> + timeout += 20;
>>> + if (timeout > VDPA_RESET_TIMEOUT_MS)
>>> + return -EIO;
>>> +
>>> + msleep(20);
>>> + }
>>
>> I wonder if it's better to do this in the vDPA parent?
>>
>> Thanks
>>
> Sorry, I didn't get you here. Do you mean vDPA parent driver (e.g.
> VDUSE)?
Yes, since the how it's expected to behave depends on the specific hardware.
Even for the spec, the behavior is transport specific:
PCI: requires reread until 0
MMIO: doesn't require but it might not work for the hardware so we
decide to change
CCW: the succeed of the ccw command means the success of the reset
Thanks
> Actually I didn't find any other place where I can do
> set_status() and get_status().
>
> Thanks,
> Yongji
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* [PATCH v10 05/17] vhost-vdpa: Fail the vhost_vdpa_set_status() on reset failure
2021-07-29 7:34 [PATCH v10 00/17] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (3 preceding siblings ...)
2021-07-29 7:34 ` [PATCH v10 04/17] vdpa: Fail the vdpa_reset() if fail to set device status to zero Xie Yongji
@ 2021-07-29 7:34 ` Xie Yongji
2021-08-03 8:10 ` Jason Wang
2021-07-29 7:34 ` [PATCH v10 06/17] vhost-vdpa: Handle the failure of vdpa_reset() Xie Yongji
` (11 subsequent siblings)
16 siblings, 1 reply; 55+ messages in thread
From: Xie Yongji @ 2021-07-29 7:34 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu, joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
Re-read the device status to ensure it's set to zero during
resetting. Otherwise, fail the vhost_vdpa_set_status() after timeout.
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
---
drivers/vhost/vdpa.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index b07aa161f7ad..dd05c1e1133c 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -157,7 +157,7 @@ static long vhost_vdpa_set_status(struct vhost_vdpa *v, u8 __user *statusp)
struct vdpa_device *vdpa = v->vdpa;
const struct vdpa_config_ops *ops = vdpa->config;
u8 status, status_old;
- int nvqs = v->nvqs;
+ int timeout = 0, nvqs = v->nvqs;
u16 i;
if (copy_from_user(&status, statusp, sizeof(status)))
@@ -173,6 +173,15 @@ static long vhost_vdpa_set_status(struct vhost_vdpa *v, u8 __user *statusp)
return -EINVAL;
ops->set_status(vdpa, status);
+ if (status == 0) {
+ while (ops->get_status(vdpa)) {
+ timeout += 20;
+ if (timeout > VDPA_RESET_TIMEOUT_MS)
+ return -EIO;
+
+ msleep(20);
+ }
+ }
if ((status & VIRTIO_CONFIG_S_DRIVER_OK) && !(status_old & VIRTIO_CONFIG_S_DRIVER_OK))
for (i = 0; i < nvqs; i++)
--
2.11.0
^ permalink raw reply related [flat|nested] 55+ messages in thread* Re: [PATCH v10 05/17] vhost-vdpa: Fail the vhost_vdpa_set_status() on reset failure
2021-07-29 7:34 ` [PATCH v10 05/17] vhost-vdpa: Fail the vhost_vdpa_set_status() on reset failure Xie Yongji
@ 2021-08-03 8:10 ` Jason Wang
2021-08-03 9:50 ` Yongji Xie
0 siblings, 1 reply; 55+ messages in thread
From: Jason Wang @ 2021-08-03 8:10 UTC (permalink / raw)
To: Xie Yongji, mst, stefanha, sgarzare, parav, hch,
christian.brauner, rdunlap, willy, viro, axboe, bcrl, corbet,
mika.penttila, dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu,
joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
在 2021/7/29 下午3:34, Xie Yongji 写道:
> Re-read the device status to ensure it's set to zero during
> resetting. Otherwise, fail the vhost_vdpa_set_status() after timeout.
>
> Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> ---
> drivers/vhost/vdpa.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
> index b07aa161f7ad..dd05c1e1133c 100644
> --- a/drivers/vhost/vdpa.c
> +++ b/drivers/vhost/vdpa.c
> @@ -157,7 +157,7 @@ static long vhost_vdpa_set_status(struct vhost_vdpa *v, u8 __user *statusp)
> struct vdpa_device *vdpa = v->vdpa;
> const struct vdpa_config_ops *ops = vdpa->config;
> u8 status, status_old;
> - int nvqs = v->nvqs;
> + int timeout = 0, nvqs = v->nvqs;
> u16 i;
>
> if (copy_from_user(&status, statusp, sizeof(status)))
> @@ -173,6 +173,15 @@ static long vhost_vdpa_set_status(struct vhost_vdpa *v, u8 __user *statusp)
> return -EINVAL;
>
> ops->set_status(vdpa, status);
> + if (status == 0) {
> + while (ops->get_status(vdpa)) {
> + timeout += 20;
> + if (timeout > VDPA_RESET_TIMEOUT_MS)
> + return -EIO;
> +
> + msleep(20);
> + }
Spec has introduced the reset a one of the basic facility. And consider
we differ reset here.
This makes me think if it's better to introduce a dedicated vdpa ops for
reset?
Thanks
> + }
>
> if ((status & VIRTIO_CONFIG_S_DRIVER_OK) && !(status_old & VIRTIO_CONFIG_S_DRIVER_OK))
> for (i = 0; i < nvqs; i++)
^ permalink raw reply [flat|nested] 55+ messages in thread* Re: [PATCH v10 05/17] vhost-vdpa: Fail the vhost_vdpa_set_status() on reset failure
2021-08-03 8:10 ` Jason Wang
@ 2021-08-03 9:50 ` Yongji Xie
2021-08-04 8:33 ` Jason Wang
0 siblings, 1 reply; 55+ messages in thread
From: Yongji Xie @ 2021-08-03 9:50 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, Greg KH, He Zhe, Liu Xiaodong, Joe Perches,
songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
On Tue, Aug 3, 2021 at 4:10 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/7/29 下午3:34, Xie Yongji 写道:
> > Re-read the device status to ensure it's set to zero during
> > resetting. Otherwise, fail the vhost_vdpa_set_status() after timeout.
> >
> > Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> > ---
> > drivers/vhost/vdpa.c | 11 ++++++++++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
> > index b07aa161f7ad..dd05c1e1133c 100644
> > --- a/drivers/vhost/vdpa.c
> > +++ b/drivers/vhost/vdpa.c
> > @@ -157,7 +157,7 @@ static long vhost_vdpa_set_status(struct vhost_vdpa *v, u8 __user *statusp)
> > struct vdpa_device *vdpa = v->vdpa;
> > const struct vdpa_config_ops *ops = vdpa->config;
> > u8 status, status_old;
> > - int nvqs = v->nvqs;
> > + int timeout = 0, nvqs = v->nvqs;
> > u16 i;
> >
> > if (copy_from_user(&status, statusp, sizeof(status)))
> > @@ -173,6 +173,15 @@ static long vhost_vdpa_set_status(struct vhost_vdpa *v, u8 __user *statusp)
> > return -EINVAL;
> >
> > ops->set_status(vdpa, status);
> > + if (status == 0) {
> > + while (ops->get_status(vdpa)) {
> > + timeout += 20;
> > + if (timeout > VDPA_RESET_TIMEOUT_MS)
> > + return -EIO;
> > +
> > + msleep(20);
> > + }
>
>
> Spec has introduced the reset a one of the basic facility. And consider
> we differ reset here.
>
> This makes me think if it's better to introduce a dedicated vdpa ops for
> reset?
>
Do you mean replace the ops.set_status(vdev, 0) with the ops.reset()?
Then we can remove the timeout processing which is device specific
stuff.
Thanks,
Yongji
^ permalink raw reply [flat|nested] 55+ messages in thread* Re: [PATCH v10 05/17] vhost-vdpa: Fail the vhost_vdpa_set_status() on reset failure
2021-08-03 9:50 ` Yongji Xie
@ 2021-08-04 8:33 ` Jason Wang
0 siblings, 0 replies; 55+ messages in thread
From: Jason Wang @ 2021-08-04 8:33 UTC (permalink / raw)
To: Yongji Xie
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, Greg KH, He Zhe, Liu Xiaodong, Joe Perches,
songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
在 2021/8/3 下午5:50, Yongji Xie 写道:
> On Tue, Aug 3, 2021 at 4:10 PM Jason Wang <jasowang@redhat.com> wrote:
>>
>> 在 2021/7/29 下午3:34, Xie Yongji 写道:
>>> Re-read the device status to ensure it's set to zero during
>>> resetting. Otherwise, fail the vhost_vdpa_set_status() after timeout.
>>>
>>> Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
>>> ---
>>> drivers/vhost/vdpa.c | 11 ++++++++++-
>>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
>>> index b07aa161f7ad..dd05c1e1133c 100644
>>> --- a/drivers/vhost/vdpa.c
>>> +++ b/drivers/vhost/vdpa.c
>>> @@ -157,7 +157,7 @@ static long vhost_vdpa_set_status(struct vhost_vdpa *v, u8 __user *statusp)
>>> struct vdpa_device *vdpa = v->vdpa;
>>> const struct vdpa_config_ops *ops = vdpa->config;
>>> u8 status, status_old;
>>> - int nvqs = v->nvqs;
>>> + int timeout = 0, nvqs = v->nvqs;
>>> u16 i;
>>>
>>> if (copy_from_user(&status, statusp, sizeof(status)))
>>> @@ -173,6 +173,15 @@ static long vhost_vdpa_set_status(struct vhost_vdpa *v, u8 __user *statusp)
>>> return -EINVAL;
>>>
>>> ops->set_status(vdpa, status);
>>> + if (status == 0) {
>>> + while (ops->get_status(vdpa)) {
>>> + timeout += 20;
>>> + if (timeout > VDPA_RESET_TIMEOUT_MS)
>>> + return -EIO;
>>> +
>>> + msleep(20);
>>> + }
>>
>> Spec has introduced the reset a one of the basic facility. And consider
>> we differ reset here.
>>
>> This makes me think if it's better to introduce a dedicated vdpa ops for
>> reset?
>>
> Do you mean replace the ops.set_status(vdev, 0) with the ops.reset()?
> Then we can remove the timeout processing which is device specific
> stuff.
Exactly.
Thanks
>
> Thanks,
> Yongji
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* [PATCH v10 06/17] vhost-vdpa: Handle the failure of vdpa_reset()
2021-07-29 7:34 [PATCH v10 00/17] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (4 preceding siblings ...)
2021-07-29 7:34 ` [PATCH v10 05/17] vhost-vdpa: Fail the vhost_vdpa_set_status() on reset failure Xie Yongji
@ 2021-07-29 7:34 ` Xie Yongji
2021-07-29 7:34 ` [PATCH v10 07/17] virtio: Don't set FAILED status bit on device index allocation failure Xie Yongji
` (10 subsequent siblings)
16 siblings, 0 replies; 55+ messages in thread
From: Xie Yongji @ 2021-07-29 7:34 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu, joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
The vdpa_reset() may fail now. This adds check to its return
value and fail the vhost_vdpa_open().
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
---
drivers/vhost/vdpa.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index dd05c1e1133c..9a00b560abad 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -116,12 +116,13 @@ static void vhost_vdpa_unsetup_vq_irq(struct vhost_vdpa *v, u16 qid)
irq_bypass_unregister_producer(&vq->call_ctx.producer);
}
-static void vhost_vdpa_reset(struct vhost_vdpa *v)
+static int vhost_vdpa_reset(struct vhost_vdpa *v)
{
struct vdpa_device *vdpa = v->vdpa;
- vdpa_reset(vdpa);
v->in_batch = 0;
+
+ return vdpa_reset(vdpa);
}
static long vhost_vdpa_get_device_id(struct vhost_vdpa *v, u8 __user *argp)
@@ -872,7 +873,9 @@ static int vhost_vdpa_open(struct inode *inode, struct file *filep)
return -EBUSY;
nvqs = v->nvqs;
- vhost_vdpa_reset(v);
+ r = vhost_vdpa_reset(v);
+ if (r)
+ goto err;
vqs = kmalloc_array(nvqs, sizeof(*vqs), GFP_KERNEL);
if (!vqs) {
--
2.11.0
^ permalink raw reply related [flat|nested] 55+ messages in thread* [PATCH v10 07/17] virtio: Don't set FAILED status bit on device index allocation failure
2021-07-29 7:34 [PATCH v10 00/17] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (5 preceding siblings ...)
2021-07-29 7:34 ` [PATCH v10 06/17] vhost-vdpa: Handle the failure of vdpa_reset() Xie Yongji
@ 2021-07-29 7:34 ` Xie Yongji
2021-08-03 8:02 ` Jason Wang
2021-07-29 7:34 ` [PATCH v10 08/17] virtio_config: Add a return value to reset function Xie Yongji
` (9 subsequent siblings)
16 siblings, 1 reply; 55+ messages in thread
From: Xie Yongji @ 2021-07-29 7:34 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu, joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
We don't need to set FAILED status bit on device index allocation
failure since the device initialization hasn't been started yet.
This doesn't affect runtime, found in code review.
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
---
drivers/virtio/virtio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index 4b15c00c0a0a..a15beb6b593b 100644
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -338,7 +338,7 @@ int register_virtio_device(struct virtio_device *dev)
/* Assign a unique device index and hence name. */
err = ida_simple_get(&virtio_index_ida, 0, 0, GFP_KERNEL);
if (err < 0)
- goto out;
+ return err;
dev->index = err;
dev_set_name(&dev->dev, "virtio%u", dev->index);
--
2.11.0
^ permalink raw reply related [flat|nested] 55+ messages in thread* Re: [PATCH v10 07/17] virtio: Don't set FAILED status bit on device index allocation failure
2021-07-29 7:34 ` [PATCH v10 07/17] virtio: Don't set FAILED status bit on device index allocation failure Xie Yongji
@ 2021-08-03 8:02 ` Jason Wang
2021-08-03 9:17 ` Yongji Xie
0 siblings, 1 reply; 55+ messages in thread
From: Jason Wang @ 2021-08-03 8:02 UTC (permalink / raw)
To: Xie Yongji, mst, stefanha, sgarzare, parav, hch,
christian.brauner, rdunlap, willy, viro, axboe, bcrl, corbet,
mika.penttila, dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu,
joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
在 2021/7/29 下午3:34, Xie Yongji 写道:
> We don't need to set FAILED status bit on device index allocation
> failure since the device initialization hasn't been started yet.
> This doesn't affect runtime, found in code review.
>
> Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
Does it really harm?
Thanks
> ---
> drivers/virtio/virtio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
> index 4b15c00c0a0a..a15beb6b593b 100644
> --- a/drivers/virtio/virtio.c
> +++ b/drivers/virtio/virtio.c
> @@ -338,7 +338,7 @@ int register_virtio_device(struct virtio_device *dev)
> /* Assign a unique device index and hence name. */
> err = ida_simple_get(&virtio_index_ida, 0, 0, GFP_KERNEL);
> if (err < 0)
> - goto out;
> + return err;
>
> dev->index = err;
> dev_set_name(&dev->dev, "virtio%u", dev->index);
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH v10 07/17] virtio: Don't set FAILED status bit on device index allocation failure
2021-08-03 8:02 ` Jason Wang
@ 2021-08-03 9:17 ` Yongji Xie
0 siblings, 0 replies; 55+ messages in thread
From: Yongji Xie @ 2021-08-03 9:17 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, Greg KH, He Zhe, Liu Xiaodong, Joe Perches,
songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
On Tue, Aug 3, 2021 at 4:03 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/7/29 下午3:34, Xie Yongji 写道:
> > We don't need to set FAILED status bit on device index allocation
> > failure since the device initialization hasn't been started yet.
> > This doesn't affect runtime, found in code review.
> >
> > Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
>
>
> Does it really harm?
>
Actually not. I think I can remove this patch if we don't need it.
Thanks,
Yongji
^ permalink raw reply [flat|nested] 55+ messages in thread
* [PATCH v10 08/17] virtio_config: Add a return value to reset function
2021-07-29 7:34 [PATCH v10 00/17] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (6 preceding siblings ...)
2021-07-29 7:34 ` [PATCH v10 07/17] virtio: Don't set FAILED status bit on device index allocation failure Xie Yongji
@ 2021-07-29 7:34 ` Xie Yongji
2021-07-29 7:34 ` [PATCH v10 09/17] virtio-vdpa: Handle the failure of vdpa_reset() Xie Yongji
` (8 subsequent siblings)
16 siblings, 0 replies; 55+ messages in thread
From: Xie Yongji @ 2021-07-29 7:34 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu, joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
This adds a return value to reset function so that we can
handle the reset failure later. No functional changes.
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
---
arch/um/drivers/virtio_uml.c | 4 +++-
drivers/platform/mellanox/mlxbf-tmfifo.c | 4 +++-
drivers/remoteproc/remoteproc_virtio.c | 4 +++-
drivers/s390/virtio/virtio_ccw.c | 6 ++++--
drivers/virtio/virtio_mmio.c | 4 +++-
drivers/virtio/virtio_pci_legacy.c | 4 +++-
drivers/virtio/virtio_pci_modern.c | 4 +++-
drivers/virtio/virtio_vdpa.c | 4 +++-
include/linux/virtio_config.h | 3 ++-
9 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/arch/um/drivers/virtio_uml.c b/arch/um/drivers/virtio_uml.c
index 4412d6febade..ca02deaf9b32 100644
--- a/arch/um/drivers/virtio_uml.c
+++ b/arch/um/drivers/virtio_uml.c
@@ -828,11 +828,13 @@ static void vu_set_status(struct virtio_device *vdev, u8 status)
vu_dev->status = status;
}
-static void vu_reset(struct virtio_device *vdev)
+static int vu_reset(struct virtio_device *vdev)
{
struct virtio_uml_device *vu_dev = to_virtio_uml_device(vdev);
vu_dev->status = 0;
+
+ return 0;
}
static void vu_del_vq(struct virtqueue *vq)
diff --git a/drivers/platform/mellanox/mlxbf-tmfifo.c b/drivers/platform/mellanox/mlxbf-tmfifo.c
index 38800e86ed8a..e3c513c2d4fa 100644
--- a/drivers/platform/mellanox/mlxbf-tmfifo.c
+++ b/drivers/platform/mellanox/mlxbf-tmfifo.c
@@ -989,11 +989,13 @@ static void mlxbf_tmfifo_virtio_set_status(struct virtio_device *vdev,
}
/* Reset the device. Not much here for now. */
-static void mlxbf_tmfifo_virtio_reset(struct virtio_device *vdev)
+static int mlxbf_tmfifo_virtio_reset(struct virtio_device *vdev)
{
struct mlxbf_tmfifo_vdev *tm_vdev = mlxbf_vdev_to_tmfifo(vdev);
tm_vdev->status = 0;
+
+ return 0;
}
/* Read the value of a configuration field. */
diff --git a/drivers/remoteproc/remoteproc_virtio.c b/drivers/remoteproc/remoteproc_virtio.c
index cf4d54e98e6a..975c845b3187 100644
--- a/drivers/remoteproc/remoteproc_virtio.c
+++ b/drivers/remoteproc/remoteproc_virtio.c
@@ -191,7 +191,7 @@ static void rproc_virtio_set_status(struct virtio_device *vdev, u8 status)
dev_dbg(&vdev->dev, "status: %d\n", status);
}
-static void rproc_virtio_reset(struct virtio_device *vdev)
+static int rproc_virtio_reset(struct virtio_device *vdev)
{
struct rproc_vdev *rvdev = vdev_to_rvdev(vdev);
struct fw_rsc_vdev *rsc;
@@ -200,6 +200,8 @@ static void rproc_virtio_reset(struct virtio_device *vdev)
rsc->status = 0;
dev_dbg(&vdev->dev, "reset !\n");
+
+ return 0;
}
/* provide the vdev features as retrieved from the firmware */
diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c
index d35e7a3f7067..5221cdad531d 100644
--- a/drivers/s390/virtio/virtio_ccw.c
+++ b/drivers/s390/virtio/virtio_ccw.c
@@ -710,14 +710,14 @@ static int virtio_ccw_find_vqs(struct virtio_device *vdev, unsigned nvqs,
return ret;
}
-static void virtio_ccw_reset(struct virtio_device *vdev)
+static int virtio_ccw_reset(struct virtio_device *vdev)
{
struct virtio_ccw_device *vcdev = to_vc_device(vdev);
struct ccw1 *ccw;
ccw = ccw_device_dma_zalloc(vcdev->cdev, sizeof(*ccw));
if (!ccw)
- return;
+ return -ENOMEM;
/* Zero status bits. */
vcdev->dma_area->status = 0;
@@ -729,6 +729,8 @@ static void virtio_ccw_reset(struct virtio_device *vdev)
ccw->cda = 0;
ccw_io_helper(vcdev, ccw, VIRTIO_CCW_DOING_RESET);
ccw_device_dma_free(vcdev->cdev, ccw, sizeof(*ccw));
+
+ return 0;
}
static u64 virtio_ccw_get_features(struct virtio_device *vdev)
diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index 56128b9c46eb..c0a65efa4a65 100644
--- a/drivers/virtio/virtio_mmio.c
+++ b/drivers/virtio/virtio_mmio.c
@@ -256,12 +256,14 @@ static void vm_set_status(struct virtio_device *vdev, u8 status)
writel(status, vm_dev->base + VIRTIO_MMIO_STATUS);
}
-static void vm_reset(struct virtio_device *vdev)
+static int vm_reset(struct virtio_device *vdev)
{
struct virtio_mmio_device *vm_dev = to_virtio_mmio_device(vdev);
/* 0 status means a reset. */
writel(0, vm_dev->base + VIRTIO_MMIO_STATUS);
+
+ return 0;
}
diff --git a/drivers/virtio/virtio_pci_legacy.c b/drivers/virtio/virtio_pci_legacy.c
index d62e9835aeec..0b5d95e3efa1 100644
--- a/drivers/virtio/virtio_pci_legacy.c
+++ b/drivers/virtio/virtio_pci_legacy.c
@@ -89,7 +89,7 @@ static void vp_set_status(struct virtio_device *vdev, u8 status)
iowrite8(status, vp_dev->ioaddr + VIRTIO_PCI_STATUS);
}
-static void vp_reset(struct virtio_device *vdev)
+static int vp_reset(struct virtio_device *vdev)
{
struct virtio_pci_device *vp_dev = to_vp_device(vdev);
/* 0 status means a reset. */
@@ -99,6 +99,8 @@ static void vp_reset(struct virtio_device *vdev)
ioread8(vp_dev->ioaddr + VIRTIO_PCI_STATUS);
/* Flush pending VQ/configuration callbacks. */
vp_synchronize_vectors(vdev);
+
+ return 0;
}
static u16 vp_config_vector(struct virtio_pci_device *vp_dev, u16 vector)
diff --git a/drivers/virtio/virtio_pci_modern.c b/drivers/virtio/virtio_pci_modern.c
index 30654d3a0b41..b0cde3b2f0ff 100644
--- a/drivers/virtio/virtio_pci_modern.c
+++ b/drivers/virtio/virtio_pci_modern.c
@@ -158,7 +158,7 @@ static void vp_set_status(struct virtio_device *vdev, u8 status)
vp_modern_set_status(&vp_dev->mdev, status);
}
-static void vp_reset(struct virtio_device *vdev)
+static int vp_reset(struct virtio_device *vdev)
{
struct virtio_pci_device *vp_dev = to_vp_device(vdev);
struct virtio_pci_modern_device *mdev = &vp_dev->mdev;
@@ -174,6 +174,8 @@ static void vp_reset(struct virtio_device *vdev)
msleep(1);
/* Flush pending VQ/configuration callbacks. */
vp_synchronize_vectors(vdev);
+
+ return 0;
}
static u16 vp_config_vector(struct virtio_pci_device *vp_dev, u16 vector)
diff --git a/drivers/virtio/virtio_vdpa.c b/drivers/virtio/virtio_vdpa.c
index ff43f9b62b2f..3e666f70e829 100644
--- a/drivers/virtio/virtio_vdpa.c
+++ b/drivers/virtio/virtio_vdpa.c
@@ -97,11 +97,13 @@ static void virtio_vdpa_set_status(struct virtio_device *vdev, u8 status)
return ops->set_status(vdpa, status);
}
-static void virtio_vdpa_reset(struct virtio_device *vdev)
+static int virtio_vdpa_reset(struct virtio_device *vdev)
{
struct vdpa_device *vdpa = vd_get_vdpa(vdev);
vdpa_reset(vdpa);
+
+ return 0;
}
static bool virtio_vdpa_notify(struct virtqueue *vq)
diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
index 8519b3ae5d52..203407992c30 100644
--- a/include/linux/virtio_config.h
+++ b/include/linux/virtio_config.h
@@ -47,6 +47,7 @@ struct virtio_shm_region {
* After this, status and feature negotiation must be done again
* Device must not be reset from its vq/config callbacks, or in
* parallel with being added/removed.
+ * Returns 0 on success or error status
* @find_vqs: find virtqueues and instantiate them.
* vdev: the virtio_device
* nvqs: the number of virtqueues to find
@@ -82,7 +83,7 @@ struct virtio_config_ops {
u32 (*generation)(struct virtio_device *vdev);
u8 (*get_status)(struct virtio_device *vdev);
void (*set_status)(struct virtio_device *vdev, u8 status);
- void (*reset)(struct virtio_device *vdev);
+ int (*reset)(struct virtio_device *vdev);
int (*find_vqs)(struct virtio_device *, unsigned nvqs,
struct virtqueue *vqs[], vq_callback_t *callbacks[],
const char * const names[], const bool *ctx,
--
2.11.0
^ permalink raw reply related [flat|nested] 55+ messages in thread* [PATCH v10 09/17] virtio-vdpa: Handle the failure of vdpa_reset()
2021-07-29 7:34 [PATCH v10 00/17] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (7 preceding siblings ...)
2021-07-29 7:34 ` [PATCH v10 08/17] virtio_config: Add a return value to reset function Xie Yongji
@ 2021-07-29 7:34 ` Xie Yongji
2021-07-29 7:34 ` [PATCH v10 10/17] virtio: Handle device reset failure in register_virtio_device() Xie Yongji
` (7 subsequent siblings)
16 siblings, 0 replies; 55+ messages in thread
From: Xie Yongji @ 2021-07-29 7:34 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu, joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
The vpda_reset() may fail now. This adds check to its return
value and fail the virtio_vdpa_reset().
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
---
drivers/virtio/virtio_vdpa.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/virtio/virtio_vdpa.c b/drivers/virtio/virtio_vdpa.c
index 3e666f70e829..ebbd8471bbee 100644
--- a/drivers/virtio/virtio_vdpa.c
+++ b/drivers/virtio/virtio_vdpa.c
@@ -101,9 +101,7 @@ static int virtio_vdpa_reset(struct virtio_device *vdev)
{
struct vdpa_device *vdpa = vd_get_vdpa(vdev);
- vdpa_reset(vdpa);
-
- return 0;
+ return vdpa_reset(vdpa);
}
static bool virtio_vdpa_notify(struct virtqueue *vq)
--
2.11.0
^ permalink raw reply related [flat|nested] 55+ messages in thread* [PATCH v10 10/17] virtio: Handle device reset failure in register_virtio_device()
2021-07-29 7:34 [PATCH v10 00/17] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (8 preceding siblings ...)
2021-07-29 7:34 ` [PATCH v10 09/17] virtio-vdpa: Handle the failure of vdpa_reset() Xie Yongji
@ 2021-07-29 7:34 ` Xie Yongji
2021-08-03 8:09 ` Jason Wang
2021-07-29 7:34 ` [PATCH v10 11/17] vhost-iotlb: Add an opaque pointer for vhost IOTLB Xie Yongji
` (6 subsequent siblings)
16 siblings, 1 reply; 55+ messages in thread
From: Xie Yongji @ 2021-07-29 7:34 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu, joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
The device reset may fail in virtio-vdpa case now, so add checks to
its return value and fail the register_virtio_device().
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
---
drivers/virtio/virtio.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index a15beb6b593b..8df75425fb43 100644
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -349,7 +349,9 @@ int register_virtio_device(struct virtio_device *dev)
/* We always start by resetting the device, in case a previous
* driver messed it up. This also tests that code path a little. */
- dev->config->reset(dev);
+ err = dev->config->reset(dev);
+ if (err)
+ goto err_reset;
/* Acknowledge that we've seen the device. */
virtio_add_status(dev, VIRTIO_CONFIG_S_ACKNOWLEDGE);
@@ -362,10 +364,13 @@ int register_virtio_device(struct virtio_device *dev)
*/
err = device_add(&dev->dev);
if (err)
- ida_simple_remove(&virtio_index_ida, dev->index);
-out:
- if (err)
- virtio_add_status(dev, VIRTIO_CONFIG_S_FAILED);
+ goto err_add;
+
+ return 0;
+err_add:
+ virtio_add_status(dev, VIRTIO_CONFIG_S_FAILED);
+err_reset:
+ ida_simple_remove(&virtio_index_ida, dev->index);
return err;
}
EXPORT_SYMBOL_GPL(register_virtio_device);
--
2.11.0
^ permalink raw reply related [flat|nested] 55+ messages in thread* Re: [PATCH v10 10/17] virtio: Handle device reset failure in register_virtio_device()
2021-07-29 7:34 ` [PATCH v10 10/17] virtio: Handle device reset failure in register_virtio_device() Xie Yongji
@ 2021-08-03 8:09 ` Jason Wang
2021-08-03 9:38 ` Yongji Xie
0 siblings, 1 reply; 55+ messages in thread
From: Jason Wang @ 2021-08-03 8:09 UTC (permalink / raw)
To: Xie Yongji, mst, stefanha, sgarzare, parav, hch,
christian.brauner, rdunlap, willy, viro, axboe, bcrl, corbet,
mika.penttila, dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu,
joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
在 2021/7/29 下午3:34, Xie Yongji 写道:
> The device reset may fail in virtio-vdpa case now, so add checks to
> its return value and fail the register_virtio_device().
So the reset() would be called by the driver during remove as well, or
is it sufficient to deal only with the reset during probe?
Thanks
>
> Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> ---
> drivers/virtio/virtio.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
> index a15beb6b593b..8df75425fb43 100644
> --- a/drivers/virtio/virtio.c
> +++ b/drivers/virtio/virtio.c
> @@ -349,7 +349,9 @@ int register_virtio_device(struct virtio_device *dev)
>
> /* We always start by resetting the device, in case a previous
> * driver messed it up. This also tests that code path a little. */
> - dev->config->reset(dev);
> + err = dev->config->reset(dev);
> + if (err)
> + goto err_reset;
>
> /* Acknowledge that we've seen the device. */
> virtio_add_status(dev, VIRTIO_CONFIG_S_ACKNOWLEDGE);
> @@ -362,10 +364,13 @@ int register_virtio_device(struct virtio_device *dev)
> */
> err = device_add(&dev->dev);
> if (err)
> - ida_simple_remove(&virtio_index_ida, dev->index);
> -out:
> - if (err)
> - virtio_add_status(dev, VIRTIO_CONFIG_S_FAILED);
> + goto err_add;
> +
> + return 0;
> +err_add:
> + virtio_add_status(dev, VIRTIO_CONFIG_S_FAILED);
> +err_reset:
> + ida_simple_remove(&virtio_index_ida, dev->index);
> return err;
> }
> EXPORT_SYMBOL_GPL(register_virtio_device);
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH v10 10/17] virtio: Handle device reset failure in register_virtio_device()
2021-08-03 8:09 ` Jason Wang
@ 2021-08-03 9:38 ` Yongji Xie
2021-08-04 8:32 ` Jason Wang
0 siblings, 1 reply; 55+ messages in thread
From: Yongji Xie @ 2021-08-03 9:38 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, Greg KH, He Zhe, Liu Xiaodong, Joe Perches,
songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
On Tue, Aug 3, 2021 at 4:09 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/7/29 下午3:34, Xie Yongji 写道:
> > The device reset may fail in virtio-vdpa case now, so add checks to
> > its return value and fail the register_virtio_device().
>
>
> So the reset() would be called by the driver during remove as well, or
> is it sufficient to deal only with the reset during probe?
>
Actually there is no way to handle failure during removal. And it
should be safe with the protection of software IOTLB even if the
reset() fails.
Thanks,
Yongji
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH v10 10/17] virtio: Handle device reset failure in register_virtio_device()
2021-08-03 9:38 ` Yongji Xie
@ 2021-08-04 8:32 ` Jason Wang
2021-08-04 8:50 ` Yongji Xie
0 siblings, 1 reply; 55+ messages in thread
From: Jason Wang @ 2021-08-04 8:32 UTC (permalink / raw)
To: Yongji Xie
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, Greg KH, He Zhe, Liu Xiaodong, Joe Perches,
songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
在 2021/8/3 下午5:38, Yongji Xie 写道:
> On Tue, Aug 3, 2021 at 4:09 PM Jason Wang <jasowang@redhat.com> wrote:
>>
>> 在 2021/7/29 下午3:34, Xie Yongji 写道:
>>> The device reset may fail in virtio-vdpa case now, so add checks to
>>> its return value and fail the register_virtio_device().
>>
>> So the reset() would be called by the driver during remove as well, or
>> is it sufficient to deal only with the reset during probe?
>>
> Actually there is no way to handle failure during removal. And it
> should be safe with the protection of software IOTLB even if the
> reset() fails.
>
> Thanks,
> Yongji
If this is true, does it mean we don't even need to care about reset
failure?
Thanks
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH v10 10/17] virtio: Handle device reset failure in register_virtio_device()
2021-08-04 8:32 ` Jason Wang
@ 2021-08-04 8:50 ` Yongji Xie
2021-08-04 8:54 ` Jason Wang
0 siblings, 1 reply; 55+ messages in thread
From: Yongji Xie @ 2021-08-04 8:50 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, Greg KH, He Zhe, Liu Xiaodong, Joe Perches,
songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
On Wed, Aug 4, 2021 at 4:32 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/8/3 下午5:38, Yongji Xie 写道:
> > On Tue, Aug 3, 2021 at 4:09 PM Jason Wang <jasowang@redhat.com> wrote:
> >>
> >> 在 2021/7/29 下午3:34, Xie Yongji 写道:
> >>> The device reset may fail in virtio-vdpa case now, so add checks to
> >>> its return value and fail the register_virtio_device().
> >>
> >> So the reset() would be called by the driver during remove as well, or
> >> is it sufficient to deal only with the reset during probe?
> >>
> > Actually there is no way to handle failure during removal. And it
> > should be safe with the protection of software IOTLB even if the
> > reset() fails.
> >
> > Thanks,
> > Yongji
>
>
> If this is true, does it mean we don't even need to care about reset
> failure?
>
But we need to handle the failure in the vhost-vdpa case, isn't it?
Thanks,
Yongji
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH v10 10/17] virtio: Handle device reset failure in register_virtio_device()
2021-08-04 8:50 ` Yongji Xie
@ 2021-08-04 8:54 ` Jason Wang
2021-08-04 9:07 ` Yongji Xie
0 siblings, 1 reply; 55+ messages in thread
From: Jason Wang @ 2021-08-04 8:54 UTC (permalink / raw)
To: Yongji Xie
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, Greg KH, He Zhe, Liu Xiaodong, Joe Perches,
songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
在 2021/8/4 下午4:50, Yongji Xie 写道:
> On Wed, Aug 4, 2021 at 4:32 PM Jason Wang <jasowang@redhat.com> wrote:
>>
>> 在 2021/8/3 下午5:38, Yongji Xie 写道:
>>> On Tue, Aug 3, 2021 at 4:09 PM Jason Wang <jasowang@redhat.com> wrote:
>>>> 在 2021/7/29 下午3:34, Xie Yongji 写道:
>>>>> The device reset may fail in virtio-vdpa case now, so add checks to
>>>>> its return value and fail the register_virtio_device().
>>>> So the reset() would be called by the driver during remove as well, or
>>>> is it sufficient to deal only with the reset during probe?
>>>>
>>> Actually there is no way to handle failure during removal. And it
>>> should be safe with the protection of software IOTLB even if the
>>> reset() fails.
>>>
>>> Thanks,
>>> Yongji
>>
>> If this is true, does it mean we don't even need to care about reset
>> failure?
>>
> But we need to handle the failure in the vhost-vdpa case, isn't it?
Yes, but:
- This patch is for virtio not for vhost, if we don't care virtio, we
can avoid the changes
- For vhost, there could be two ways probably:
1) let the set_status to report error
2) require userspace to re-read for status
It looks to me you want to go with 1) and I'm not sure whether or not
it's too late to go with 2).
Thanks
>
> Thanks,
> Yongji
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH v10 10/17] virtio: Handle device reset failure in register_virtio_device()
2021-08-04 8:54 ` Jason Wang
@ 2021-08-04 9:07 ` Yongji Xie
2021-08-05 7:12 ` Jason Wang
0 siblings, 1 reply; 55+ messages in thread
From: Yongji Xie @ 2021-08-04 9:07 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, Greg KH, He Zhe, Liu Xiaodong, Joe Perches,
songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
On Wed, Aug 4, 2021 at 4:54 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/8/4 下午4:50, Yongji Xie 写道:
> > On Wed, Aug 4, 2021 at 4:32 PM Jason Wang <jasowang@redhat.com> wrote:
> >>
> >> 在 2021/8/3 下午5:38, Yongji Xie 写道:
> >>> On Tue, Aug 3, 2021 at 4:09 PM Jason Wang <jasowang@redhat.com> wrote:
> >>>> 在 2021/7/29 下午3:34, Xie Yongji 写道:
> >>>>> The device reset may fail in virtio-vdpa case now, so add checks to
> >>>>> its return value and fail the register_virtio_device().
> >>>> So the reset() would be called by the driver during remove as well, or
> >>>> is it sufficient to deal only with the reset during probe?
> >>>>
> >>> Actually there is no way to handle failure during removal. And it
> >>> should be safe with the protection of software IOTLB even if the
> >>> reset() fails.
> >>>
> >>> Thanks,
> >>> Yongji
> >>
> >> If this is true, does it mean we don't even need to care about reset
> >> failure?
> >>
> > But we need to handle the failure in the vhost-vdpa case, isn't it?
>
>
> Yes, but:
>
> - This patch is for virtio not for vhost, if we don't care virtio, we
> can avoid the changes
> - For vhost, there could be two ways probably:
>
> 1) let the set_status to report error
> 2) require userspace to re-read for status
>
> It looks to me you want to go with 1) and I'm not sure whether or not
> it's too late to go with 2).
>
Looks like 2) can't work if reset failure happens in
vhost_vdpa_release() and vhost_vdpa_open().
Thanks,
Yongji
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH v10 10/17] virtio: Handle device reset failure in register_virtio_device()
2021-08-04 9:07 ` Yongji Xie
@ 2021-08-05 7:12 ` Jason Wang
0 siblings, 0 replies; 55+ messages in thread
From: Jason Wang @ 2021-08-05 7:12 UTC (permalink / raw)
To: Yongji Xie
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, Greg KH, He Zhe, Liu Xiaodong, Joe Perches,
songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
在 2021/8/4 下午5:07, Yongji Xie 写道:
> On Wed, Aug 4, 2021 at 4:54 PM Jason Wang <jasowang@redhat.com> wrote:
>>
>> 在 2021/8/4 下午4:50, Yongji Xie 写道:
>>> On Wed, Aug 4, 2021 at 4:32 PM Jason Wang <jasowang@redhat.com> wrote:
>>>> 在 2021/8/3 下午5:38, Yongji Xie 写道:
>>>>> On Tue, Aug 3, 2021 at 4:09 PM Jason Wang <jasowang@redhat.com> wrote:
>>>>>> 在 2021/7/29 下午3:34, Xie Yongji 写道:
>>>>>>> The device reset may fail in virtio-vdpa case now, so add checks to
>>>>>>> its return value and fail the register_virtio_device().
>>>>>> So the reset() would be called by the driver during remove as well, or
>>>>>> is it sufficient to deal only with the reset during probe?
>>>>>>
>>>>> Actually there is no way to handle failure during removal. And it
>>>>> should be safe with the protection of software IOTLB even if the
>>>>> reset() fails.
>>>>>
>>>>> Thanks,
>>>>> Yongji
>>>> If this is true, does it mean we don't even need to care about reset
>>>> failure?
>>>>
>>> But we need to handle the failure in the vhost-vdpa case, isn't it?
>>
>> Yes, but:
>>
>> - This patch is for virtio not for vhost, if we don't care virtio, we
>> can avoid the changes
>> - For vhost, there could be two ways probably:
>>
>> 1) let the set_status to report error
>> 2) require userspace to re-read for status
>>
>> It looks to me you want to go with 1) and I'm not sure whether or not
>> it's too late to go with 2).
>>
> Looks like 2) can't work if reset failure happens in
> vhost_vdpa_release() and vhost_vdpa_open().
Yes, you're right.
Thanks
>
> Thanks,
> Yongji
>
^ permalink raw reply [flat|nested] 55+ messages in thread
* [PATCH v10 11/17] vhost-iotlb: Add an opaque pointer for vhost IOTLB
2021-07-29 7:34 [PATCH v10 00/17] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (9 preceding siblings ...)
2021-07-29 7:34 ` [PATCH v10 10/17] virtio: Handle device reset failure in register_virtio_device() Xie Yongji
@ 2021-07-29 7:34 ` Xie Yongji
2021-07-29 7:34 ` [PATCH v10 12/17] vdpa: Add an opaque pointer for vdpa_config_ops.dma_map() Xie Yongji
` (5 subsequent siblings)
16 siblings, 0 replies; 55+ messages in thread
From: Xie Yongji @ 2021-07-29 7:34 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu, joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
Add an opaque pointer for vhost IOTLB. And introduce
vhost_iotlb_add_range_ctx() to accept it.
Suggested-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
Acked-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/iotlb.c | 20 ++++++++++++++++----
include/linux/vhost_iotlb.h | 3 +++
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/vhost/iotlb.c b/drivers/vhost/iotlb.c
index 0582079e4bcc..670d56c879e5 100644
--- a/drivers/vhost/iotlb.c
+++ b/drivers/vhost/iotlb.c
@@ -36,19 +36,21 @@ void vhost_iotlb_map_free(struct vhost_iotlb *iotlb,
EXPORT_SYMBOL_GPL(vhost_iotlb_map_free);
/**
- * vhost_iotlb_add_range - add a new range to vhost IOTLB
+ * vhost_iotlb_add_range_ctx - add a new range to vhost IOTLB
* @iotlb: the IOTLB
* @start: start of the IOVA range
* @last: last of IOVA range
* @addr: the address that is mapped to @start
* @perm: access permission of this range
+ * @opaque: the opaque pointer for the new mapping
*
* Returns an error last is smaller than start or memory allocation
* fails
*/
-int vhost_iotlb_add_range(struct vhost_iotlb *iotlb,
- u64 start, u64 last,
- u64 addr, unsigned int perm)
+int vhost_iotlb_add_range_ctx(struct vhost_iotlb *iotlb,
+ u64 start, u64 last,
+ u64 addr, unsigned int perm,
+ void *opaque)
{
struct vhost_iotlb_map *map;
@@ -71,6 +73,7 @@ int vhost_iotlb_add_range(struct vhost_iotlb *iotlb,
map->last = last;
map->addr = addr;
map->perm = perm;
+ map->opaque = opaque;
iotlb->nmaps++;
vhost_iotlb_itree_insert(map, &iotlb->root);
@@ -80,6 +83,15 @@ int vhost_iotlb_add_range(struct vhost_iotlb *iotlb,
return 0;
}
+EXPORT_SYMBOL_GPL(vhost_iotlb_add_range_ctx);
+
+int vhost_iotlb_add_range(struct vhost_iotlb *iotlb,
+ u64 start, u64 last,
+ u64 addr, unsigned int perm)
+{
+ return vhost_iotlb_add_range_ctx(iotlb, start, last,
+ addr, perm, NULL);
+}
EXPORT_SYMBOL_GPL(vhost_iotlb_add_range);
/**
diff --git a/include/linux/vhost_iotlb.h b/include/linux/vhost_iotlb.h
index 6b09b786a762..2d0e2f52f938 100644
--- a/include/linux/vhost_iotlb.h
+++ b/include/linux/vhost_iotlb.h
@@ -17,6 +17,7 @@ struct vhost_iotlb_map {
u32 perm;
u32 flags_padding;
u64 __subtree_last;
+ void *opaque;
};
#define VHOST_IOTLB_FLAG_RETIRE 0x1
@@ -29,6 +30,8 @@ struct vhost_iotlb {
unsigned int flags;
};
+int vhost_iotlb_add_range_ctx(struct vhost_iotlb *iotlb, u64 start, u64 last,
+ u64 addr, unsigned int perm, void *opaque);
int vhost_iotlb_add_range(struct vhost_iotlb *iotlb, u64 start, u64 last,
u64 addr, unsigned int perm);
void vhost_iotlb_del_range(struct vhost_iotlb *iotlb, u64 start, u64 last);
--
2.11.0
^ permalink raw reply related [flat|nested] 55+ messages in thread* [PATCH v10 12/17] vdpa: Add an opaque pointer for vdpa_config_ops.dma_map()
2021-07-29 7:34 [PATCH v10 00/17] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (10 preceding siblings ...)
2021-07-29 7:34 ` [PATCH v10 11/17] vhost-iotlb: Add an opaque pointer for vhost IOTLB Xie Yongji
@ 2021-07-29 7:34 ` Xie Yongji
2021-07-29 7:34 ` [PATCH v10 13/17] vdpa: factor out vhost_vdpa_pa_map() and vhost_vdpa_pa_unmap() Xie Yongji
` (4 subsequent siblings)
16 siblings, 0 replies; 55+ messages in thread
From: Xie Yongji @ 2021-07-29 7:34 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu, joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
Add an opaque pointer for DMA mapping.
Suggested-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
Acked-by: Jason Wang <jasowang@redhat.com>
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 6 +++---
drivers/vhost/vdpa.c | 2 +-
include/linux/vdpa.h | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 72167963421b..f456f4baf86d 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -542,14 +542,14 @@ static int vdpasim_set_map(struct vdpa_device *vdpa,
}
static int vdpasim_dma_map(struct vdpa_device *vdpa, u64 iova, u64 size,
- u64 pa, u32 perm)
+ u64 pa, u32 perm, void *opaque)
{
struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
int ret;
spin_lock(&vdpasim->iommu_lock);
- ret = vhost_iotlb_add_range(vdpasim->iommu, iova, iova + size - 1, pa,
- perm);
+ ret = vhost_iotlb_add_range_ctx(vdpasim->iommu, iova, iova + size - 1,
+ pa, perm, opaque);
spin_unlock(&vdpasim->iommu_lock);
return ret;
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 9a00b560abad..05536ada6d93 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -578,7 +578,7 @@ static int vhost_vdpa_map(struct vhost_vdpa *v,
return r;
if (ops->dma_map) {
- r = ops->dma_map(vdpa, iova, size, pa, perm);
+ r = ops->dma_map(vdpa, iova, size, pa, perm, NULL);
} else if (ops->set_map) {
if (!v->in_batch)
r = ops->set_map(vdpa, dev->iotlb);
diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
index d1a80ef05089..4655afc1359b 100644
--- a/include/linux/vdpa.h
+++ b/include/linux/vdpa.h
@@ -268,7 +268,7 @@ struct vdpa_config_ops {
/* DMA ops */
int (*set_map)(struct vdpa_device *vdev, struct vhost_iotlb *iotlb);
int (*dma_map)(struct vdpa_device *vdev, u64 iova, u64 size,
- u64 pa, u32 perm);
+ u64 pa, u32 perm, void *opaque);
int (*dma_unmap)(struct vdpa_device *vdev, u64 iova, u64 size);
/* Free device resources */
--
2.11.0
^ permalink raw reply related [flat|nested] 55+ messages in thread* [PATCH v10 13/17] vdpa: factor out vhost_vdpa_pa_map() and vhost_vdpa_pa_unmap()
2021-07-29 7:34 [PATCH v10 00/17] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (11 preceding siblings ...)
2021-07-29 7:34 ` [PATCH v10 12/17] vdpa: Add an opaque pointer for vdpa_config_ops.dma_map() Xie Yongji
@ 2021-07-29 7:34 ` Xie Yongji
2021-07-29 7:35 ` [PATCH v10 14/17] vdpa: Support transferring virtual addressing during DMA mapping Xie Yongji
` (3 subsequent siblings)
16 siblings, 0 replies; 55+ messages in thread
From: Xie Yongji @ 2021-07-29 7:34 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu, joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
The upcoming patch is going to support VA mapping/unmapping.
So let's factor out the logic of PA mapping/unmapping firstly
to make the code more readable.
Suggested-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
Acked-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/vdpa.c | 55 +++++++++++++++++++++++++++++++++-------------------
1 file changed, 35 insertions(+), 20 deletions(-)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 05536ada6d93..dec43895e84b 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -511,7 +511,7 @@ static long vhost_vdpa_unlocked_ioctl(struct file *filep,
return r;
}
-static void vhost_vdpa_iotlb_unmap(struct vhost_vdpa *v, u64 start, u64 last)
+static void vhost_vdpa_pa_unmap(struct vhost_vdpa *v, u64 start, u64 last)
{
struct vhost_dev *dev = &v->vdev;
struct vhost_iotlb *iotlb = dev->iotlb;
@@ -533,6 +533,11 @@ static void vhost_vdpa_iotlb_unmap(struct vhost_vdpa *v, u64 start, u64 last)
}
}
+static void vhost_vdpa_iotlb_unmap(struct vhost_vdpa *v, u64 start, u64 last)
+{
+ return vhost_vdpa_pa_unmap(v, start, last);
+}
+
static void vhost_vdpa_iotlb_free(struct vhost_vdpa *v)
{
struct vhost_dev *dev = &v->vdev;
@@ -613,38 +618,28 @@ static void vhost_vdpa_unmap(struct vhost_vdpa *v, u64 iova, u64 size)
}
}
-static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v,
- struct vhost_iotlb_msg *msg)
+static int vhost_vdpa_pa_map(struct vhost_vdpa *v,
+ u64 iova, u64 size, u64 uaddr, u32 perm)
{
struct vhost_dev *dev = &v->vdev;
- struct vhost_iotlb *iotlb = dev->iotlb;
struct page **page_list;
unsigned long list_size = PAGE_SIZE / sizeof(struct page *);
unsigned int gup_flags = FOLL_LONGTERM;
unsigned long npages, cur_base, map_pfn, last_pfn = 0;
unsigned long lock_limit, sz2pin, nchunks, i;
- u64 iova = msg->iova;
+ u64 start = iova;
long pinned;
int ret = 0;
- if (msg->iova < v->range.first || !msg->size ||
- msg->iova > U64_MAX - msg->size + 1 ||
- msg->iova + msg->size - 1 > v->range.last)
- return -EINVAL;
-
- if (vhost_iotlb_itree_first(iotlb, msg->iova,
- msg->iova + msg->size - 1))
- return -EEXIST;
-
/* Limit the use of memory for bookkeeping */
page_list = (struct page **) __get_free_page(GFP_KERNEL);
if (!page_list)
return -ENOMEM;
- if (msg->perm & VHOST_ACCESS_WO)
+ if (perm & VHOST_ACCESS_WO)
gup_flags |= FOLL_WRITE;
- npages = PAGE_ALIGN(msg->size + (iova & ~PAGE_MASK)) >> PAGE_SHIFT;
+ npages = PAGE_ALIGN(size + (iova & ~PAGE_MASK)) >> PAGE_SHIFT;
if (!npages) {
ret = -EINVAL;
goto free;
@@ -658,7 +653,7 @@ static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v,
goto unlock;
}
- cur_base = msg->uaddr & PAGE_MASK;
+ cur_base = uaddr & PAGE_MASK;
iova &= PAGE_MASK;
nchunks = 0;
@@ -689,7 +684,7 @@ static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v,
csize = (last_pfn - map_pfn + 1) << PAGE_SHIFT;
ret = vhost_vdpa_map(v, iova, csize,
map_pfn << PAGE_SHIFT,
- msg->perm);
+ perm);
if (ret) {
/*
* Unpin the pages that are left unmapped
@@ -718,7 +713,7 @@ static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v,
/* Pin the rest chunk */
ret = vhost_vdpa_map(v, iova, (last_pfn - map_pfn + 1) << PAGE_SHIFT,
- map_pfn << PAGE_SHIFT, msg->perm);
+ map_pfn << PAGE_SHIFT, perm);
out:
if (ret) {
if (nchunks) {
@@ -737,13 +732,33 @@ static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v,
for (pfn = map_pfn; pfn <= last_pfn; pfn++)
unpin_user_page(pfn_to_page(pfn));
}
- vhost_vdpa_unmap(v, msg->iova, msg->size);
+ vhost_vdpa_unmap(v, start, size);
}
unlock:
mmap_read_unlock(dev->mm);
free:
free_page((unsigned long)page_list);
return ret;
+
+}
+
+static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v,
+ struct vhost_iotlb_msg *msg)
+{
+ struct vhost_dev *dev = &v->vdev;
+ struct vhost_iotlb *iotlb = dev->iotlb;
+
+ if (msg->iova < v->range.first || !msg->size ||
+ msg->iova > U64_MAX - msg->size + 1 ||
+ msg->iova + msg->size - 1 > v->range.last)
+ return -EINVAL;
+
+ if (vhost_iotlb_itree_first(iotlb, msg->iova,
+ msg->iova + msg->size - 1))
+ return -EEXIST;
+
+ return vhost_vdpa_pa_map(v, msg->iova, msg->size, msg->uaddr,
+ msg->perm);
}
static int vhost_vdpa_process_iotlb_msg(struct vhost_dev *dev,
--
2.11.0
^ permalink raw reply related [flat|nested] 55+ messages in thread* [PATCH v10 14/17] vdpa: Support transferring virtual addressing during DMA mapping
2021-07-29 7:34 [PATCH v10 00/17] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (12 preceding siblings ...)
2021-07-29 7:34 ` [PATCH v10 13/17] vdpa: factor out vhost_vdpa_pa_map() and vhost_vdpa_pa_unmap() Xie Yongji
@ 2021-07-29 7:35 ` Xie Yongji
2021-07-29 7:35 ` [PATCH v10 15/17] vduse: Implement an MMU-based software IOTLB Xie Yongji
` (2 subsequent siblings)
16 siblings, 0 replies; 55+ messages in thread
From: Xie Yongji @ 2021-07-29 7:35 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu, joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
This patch introduces an attribute for vDPA device to indicate
whether virtual address can be used. If vDPA device driver set
it, vhost-vdpa bus driver will not pin user page and transfer
userspace virtual address instead of physical address during
DMA mapping. And corresponding vma->vm_file and offset will be
also passed as an opaque pointer.
Suggested-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
Acked-by: Jason Wang <jasowang@redhat.com>
---
drivers/vdpa/ifcvf/ifcvf_main.c | 2 +-
drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +-
drivers/vdpa/vdpa.c | 9 +++-
drivers/vdpa/vdpa_sim/vdpa_sim.c | 2 +-
drivers/vdpa/virtio_pci/vp_vdpa.c | 2 +-
drivers/vhost/vdpa.c | 99 ++++++++++++++++++++++++++++++++++-----
include/linux/vdpa.h | 19 ++++++--
7 files changed, 116 insertions(+), 19 deletions(-)
diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c b/drivers/vdpa/ifcvf/ifcvf_main.c
index b4b89a66607f..fc848aafe5a9 100644
--- a/drivers/vdpa/ifcvf/ifcvf_main.c
+++ b/drivers/vdpa/ifcvf/ifcvf_main.c
@@ -492,7 +492,7 @@ static int ifcvf_probe(struct pci_dev *pdev, const struct pci_device_id *id)
}
adapter = vdpa_alloc_device(struct ifcvf_adapter, vdpa,
- dev, &ifc_vdpa_ops, NULL);
+ dev, &ifc_vdpa_ops, NULL, false);
if (adapter == NULL) {
IFCVF_ERR(pdev, "Failed to allocate vDPA structure");
return -ENOMEM;
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index 683452c41a36..79cb2f130bf0 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -2035,7 +2035,7 @@ static int mlx5_vdpa_dev_add(struct vdpa_mgmt_dev *v_mdev, const char *name)
max_vqs = min_t(u32, max_vqs, MLX5_MAX_SUPPORTED_VQS);
ndev = vdpa_alloc_device(struct mlx5_vdpa_net, mvdev.vdev, mdev->device, &mlx5_vdpa_ops,
- name);
+ name, false);
if (IS_ERR(ndev))
return PTR_ERR(ndev);
diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c
index d77d59811389..41377df674d5 100644
--- a/drivers/vdpa/vdpa.c
+++ b/drivers/vdpa/vdpa.c
@@ -71,6 +71,7 @@ static void vdpa_release_dev(struct device *d)
* @config: the bus operations that is supported by this device
* @size: size of the parent structure that contains private data
* @name: name of the vdpa device; optional.
+ * @use_va: indicate whether virtual address must be used by this device
*
* Driver should use vdpa_alloc_device() wrapper macro instead of
* using this directly.
@@ -80,7 +81,8 @@ static void vdpa_release_dev(struct device *d)
*/
struct vdpa_device *__vdpa_alloc_device(struct device *parent,
const struct vdpa_config_ops *config,
- size_t size, const char *name)
+ size_t size, const char *name,
+ bool use_va)
{
struct vdpa_device *vdev;
int err = -EINVAL;
@@ -91,6 +93,10 @@ struct vdpa_device *__vdpa_alloc_device(struct device *parent,
if (!!config->dma_map != !!config->dma_unmap)
goto err;
+ /* It should only work for the device that use on-chip IOMMU */
+ if (use_va && !(config->dma_map || config->set_map))
+ goto err;
+
err = -ENOMEM;
vdev = kzalloc(size, GFP_KERNEL);
if (!vdev)
@@ -106,6 +112,7 @@ struct vdpa_device *__vdpa_alloc_device(struct device *parent,
vdev->index = err;
vdev->config = config;
vdev->features_valid = false;
+ vdev->use_va = use_va;
if (name)
err = dev_set_name(&vdev->dev, "%s", name);
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index f456f4baf86d..472d573d755c 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -250,7 +250,7 @@ struct vdpasim *vdpasim_create(struct vdpasim_dev_attr *dev_attr)
ops = &vdpasim_config_ops;
vdpasim = vdpa_alloc_device(struct vdpasim, vdpa, NULL, ops,
- dev_attr->name);
+ dev_attr->name, false);
if (!vdpasim)
goto err_alloc;
diff --git a/drivers/vdpa/virtio_pci/vp_vdpa.c b/drivers/vdpa/virtio_pci/vp_vdpa.c
index ee723c645aec..c828b9f9d92a 100644
--- a/drivers/vdpa/virtio_pci/vp_vdpa.c
+++ b/drivers/vdpa/virtio_pci/vp_vdpa.c
@@ -435,7 +435,7 @@ static int vp_vdpa_probe(struct pci_dev *pdev, const struct pci_device_id *id)
return ret;
vp_vdpa = vdpa_alloc_device(struct vp_vdpa, vdpa,
- dev, &vp_vdpa_ops, NULL);
+ dev, &vp_vdpa_ops, NULL, false);
if (vp_vdpa == NULL) {
dev_err(dev, "vp_vdpa: Failed to allocate vDPA structure\n");
return -ENOMEM;
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index dec43895e84b..975ae8b8606a 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -533,8 +533,28 @@ static void vhost_vdpa_pa_unmap(struct vhost_vdpa *v, u64 start, u64 last)
}
}
+static void vhost_vdpa_va_unmap(struct vhost_vdpa *v, u64 start, u64 last)
+{
+ struct vhost_dev *dev = &v->vdev;
+ struct vhost_iotlb *iotlb = dev->iotlb;
+ struct vhost_iotlb_map *map;
+ struct vdpa_map_file *map_file;
+
+ while ((map = vhost_iotlb_itree_first(iotlb, start, last)) != NULL) {
+ map_file = (struct vdpa_map_file *)map->opaque;
+ fput(map_file->file);
+ kfree(map_file);
+ vhost_iotlb_map_free(iotlb, map);
+ }
+}
+
static void vhost_vdpa_iotlb_unmap(struct vhost_vdpa *v, u64 start, u64 last)
{
+ struct vdpa_device *vdpa = v->vdpa;
+
+ if (vdpa->use_va)
+ return vhost_vdpa_va_unmap(v, start, last);
+
return vhost_vdpa_pa_unmap(v, start, last);
}
@@ -569,21 +589,21 @@ static int perm_to_iommu_flags(u32 perm)
return flags | IOMMU_CACHE;
}
-static int vhost_vdpa_map(struct vhost_vdpa *v,
- u64 iova, u64 size, u64 pa, u32 perm)
+static int vhost_vdpa_map(struct vhost_vdpa *v, u64 iova,
+ u64 size, u64 pa, u32 perm, void *opaque)
{
struct vhost_dev *dev = &v->vdev;
struct vdpa_device *vdpa = v->vdpa;
const struct vdpa_config_ops *ops = vdpa->config;
int r = 0;
- r = vhost_iotlb_add_range(dev->iotlb, iova, iova + size - 1,
- pa, perm);
+ r = vhost_iotlb_add_range_ctx(dev->iotlb, iova, iova + size - 1,
+ pa, perm, opaque);
if (r)
return r;
if (ops->dma_map) {
- r = ops->dma_map(vdpa, iova, size, pa, perm, NULL);
+ r = ops->dma_map(vdpa, iova, size, pa, perm, opaque);
} else if (ops->set_map) {
if (!v->in_batch)
r = ops->set_map(vdpa, dev->iotlb);
@@ -591,13 +611,15 @@ static int vhost_vdpa_map(struct vhost_vdpa *v,
r = iommu_map(v->domain, iova, pa, size,
perm_to_iommu_flags(perm));
}
-
- if (r)
+ if (r) {
vhost_iotlb_del_range(dev->iotlb, iova, iova + size - 1);
- else
+ return r;
+ }
+
+ if (!vdpa->use_va)
atomic64_add(size >> PAGE_SHIFT, &dev->mm->pinned_vm);
- return r;
+ return 0;
}
static void vhost_vdpa_unmap(struct vhost_vdpa *v, u64 iova, u64 size)
@@ -618,6 +640,56 @@ static void vhost_vdpa_unmap(struct vhost_vdpa *v, u64 iova, u64 size)
}
}
+static int vhost_vdpa_va_map(struct vhost_vdpa *v,
+ u64 iova, u64 size, u64 uaddr, u32 perm)
+{
+ struct vhost_dev *dev = &v->vdev;
+ u64 offset, map_size, map_iova = iova;
+ struct vdpa_map_file *map_file;
+ struct vm_area_struct *vma;
+ int ret;
+
+ mmap_read_lock(dev->mm);
+
+ while (size) {
+ vma = find_vma(dev->mm, uaddr);
+ if (!vma) {
+ ret = -EINVAL;
+ break;
+ }
+ map_size = min(size, vma->vm_end - uaddr);
+ if (!(vma->vm_file && (vma->vm_flags & VM_SHARED) &&
+ !(vma->vm_flags & (VM_IO | VM_PFNMAP))))
+ goto next;
+
+ map_file = kzalloc(sizeof(*map_file), GFP_KERNEL);
+ if (!map_file) {
+ ret = -ENOMEM;
+ break;
+ }
+ offset = (vma->vm_pgoff << PAGE_SHIFT) + uaddr - vma->vm_start;
+ map_file->offset = offset;
+ map_file->file = get_file(vma->vm_file);
+ ret = vhost_vdpa_map(v, map_iova, map_size, uaddr,
+ perm, map_file);
+ if (ret) {
+ fput(map_file->file);
+ kfree(map_file);
+ break;
+ }
+next:
+ size -= map_size;
+ uaddr += map_size;
+ map_iova += map_size;
+ }
+ if (ret)
+ vhost_vdpa_unmap(v, iova, map_iova - iova);
+
+ mmap_read_unlock(dev->mm);
+
+ return ret;
+}
+
static int vhost_vdpa_pa_map(struct vhost_vdpa *v,
u64 iova, u64 size, u64 uaddr, u32 perm)
{
@@ -684,7 +756,7 @@ static int vhost_vdpa_pa_map(struct vhost_vdpa *v,
csize = (last_pfn - map_pfn + 1) << PAGE_SHIFT;
ret = vhost_vdpa_map(v, iova, csize,
map_pfn << PAGE_SHIFT,
- perm);
+ perm, NULL);
if (ret) {
/*
* Unpin the pages that are left unmapped
@@ -713,7 +785,7 @@ static int vhost_vdpa_pa_map(struct vhost_vdpa *v,
/* Pin the rest chunk */
ret = vhost_vdpa_map(v, iova, (last_pfn - map_pfn + 1) << PAGE_SHIFT,
- map_pfn << PAGE_SHIFT, perm);
+ map_pfn << PAGE_SHIFT, perm, NULL);
out:
if (ret) {
if (nchunks) {
@@ -746,6 +818,7 @@ static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v,
struct vhost_iotlb_msg *msg)
{
struct vhost_dev *dev = &v->vdev;
+ struct vdpa_device *vdpa = v->vdpa;
struct vhost_iotlb *iotlb = dev->iotlb;
if (msg->iova < v->range.first || !msg->size ||
@@ -757,6 +830,10 @@ static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v,
msg->iova + msg->size - 1))
return -EEXIST;
+ if (vdpa->use_va)
+ return vhost_vdpa_va_map(v, msg->iova, msg->size,
+ msg->uaddr, msg->perm);
+
return vhost_vdpa_pa_map(v, msg->iova, msg->size, msg->uaddr,
msg->perm);
}
diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
index 4655afc1359b..005e718e4e09 100644
--- a/include/linux/vdpa.h
+++ b/include/linux/vdpa.h
@@ -66,6 +66,7 @@ struct vdpa_mgmt_dev;
* @config: the configuration ops for this device.
* @index: device index
* @features_valid: were features initialized? for legacy guests
+ * @use_va: indicate whether virtual address must be used by this device
* @nvqs: maximum number of supported virtqueues
* @mdev: management device pointer; caller must setup when registering device as part
* of dev_add() mgmtdev ops callback before invoking _vdpa_register_device().
@@ -76,6 +77,7 @@ struct vdpa_device {
const struct vdpa_config_ops *config;
unsigned int index;
bool features_valid;
+ bool use_va;
int nvqs;
struct vdpa_mgmt_dev *mdev;
};
@@ -91,6 +93,16 @@ struct vdpa_iova_range {
};
/**
+ * Corresponding file area for device memory mapping
+ * @file: vma->vm_file for the mapping
+ * @offset: mapping offset in the vm_file
+ */
+struct vdpa_map_file {
+ struct file *file;
+ u64 offset;
+};
+
+/**
* struct vdpa_config_ops - operations for configuring a vDPA device.
* Note: vDPA device drivers are required to implement all of the
* operations unless it is mentioned to be optional in the following
@@ -277,14 +289,15 @@ struct vdpa_config_ops {
struct vdpa_device *__vdpa_alloc_device(struct device *parent,
const struct vdpa_config_ops *config,
- size_t size, const char *name);
+ size_t size, const char *name,
+ bool use_va);
-#define vdpa_alloc_device(dev_struct, member, parent, config, name) \
+#define vdpa_alloc_device(dev_struct, member, parent, config, name, use_va) \
container_of(__vdpa_alloc_device( \
parent, config, \
sizeof(dev_struct) + \
BUILD_BUG_ON_ZERO(offsetof( \
- dev_struct, member)), name), \
+ dev_struct, member)), name, use_va), \
dev_struct, member)
int vdpa_register_device(struct vdpa_device *vdev, int nvqs);
--
2.11.0
^ permalink raw reply related [flat|nested] 55+ messages in thread* [PATCH v10 15/17] vduse: Implement an MMU-based software IOTLB
2021-07-29 7:34 [PATCH v10 00/17] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (13 preceding siblings ...)
2021-07-29 7:35 ` [PATCH v10 14/17] vdpa: Support transferring virtual addressing during DMA mapping Xie Yongji
@ 2021-07-29 7:35 ` Xie Yongji
2021-07-29 7:35 ` [PATCH v10 16/17] vduse: Introduce VDUSE - vDPA Device in Userspace Xie Yongji
2021-07-29 7:35 ` [PATCH v10 17/17] Documentation: Add documentation for VDUSE Xie Yongji
16 siblings, 0 replies; 55+ messages in thread
From: Xie Yongji @ 2021-07-29 7:35 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu, joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
This implements an MMU-based software IOTLB to support mapping
kernel dma buffer into userspace dynamically. The basic idea
behind it is treating MMU (VA->PA) as IOMMU (IOVA->PA). The
software IOTLB will set up MMU mapping instead of IOMMU mapping
for the DMA transfer so that the userspace process is able to
use its virtual address to access the dma buffer in kernel.
To avoid security issue, a bounce-buffering mechanism is
introduced to prevent userspace accessing the original buffer
directly which may contain other kernel data. During the mapping,
unmapping, the software IOTLB will copy the data from the original
buffer to the bounce buffer and back, depending on the direction
of the transfer. And the bounce-buffer addresses will be mapped
into the user address space instead of the original one.
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
Acked-by: Jason Wang <jasowang@redhat.com>
---
drivers/vdpa/vdpa_user/iova_domain.c | 545 +++++++++++++++++++++++++++++++++++
drivers/vdpa/vdpa_user/iova_domain.h | 73 +++++
2 files changed, 618 insertions(+)
create mode 100644 drivers/vdpa/vdpa_user/iova_domain.c
create mode 100644 drivers/vdpa/vdpa_user/iova_domain.h
diff --git a/drivers/vdpa/vdpa_user/iova_domain.c b/drivers/vdpa/vdpa_user/iova_domain.c
new file mode 100644
index 000000000000..1daae2608860
--- /dev/null
+++ b/drivers/vdpa/vdpa_user/iova_domain.c
@@ -0,0 +1,545 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * MMU-based software IOTLB.
+ *
+ * Copyright (C) 2020-2021 Bytedance Inc. and/or its affiliates. All rights reserved.
+ *
+ * Author: Xie Yongji <xieyongji@bytedance.com>
+ *
+ */
+
+#include <linux/slab.h>
+#include <linux/file.h>
+#include <linux/anon_inodes.h>
+#include <linux/highmem.h>
+#include <linux/vmalloc.h>
+#include <linux/vdpa.h>
+
+#include "iova_domain.h"
+
+static int vduse_iotlb_add_range(struct vduse_iova_domain *domain,
+ u64 start, u64 last,
+ u64 addr, unsigned int perm,
+ struct file *file, u64 offset)
+{
+ struct vdpa_map_file *map_file;
+ int ret;
+
+ map_file = kmalloc(sizeof(*map_file), GFP_ATOMIC);
+ if (!map_file)
+ return -ENOMEM;
+
+ map_file->file = get_file(file);
+ map_file->offset = offset;
+
+ ret = vhost_iotlb_add_range_ctx(domain->iotlb, start, last,
+ addr, perm, map_file);
+ if (ret) {
+ fput(map_file->file);
+ kfree(map_file);
+ return ret;
+ }
+ return 0;
+}
+
+static void vduse_iotlb_del_range(struct vduse_iova_domain *domain,
+ u64 start, u64 last)
+{
+ struct vdpa_map_file *map_file;
+ struct vhost_iotlb_map *map;
+
+ while ((map = vhost_iotlb_itree_first(domain->iotlb, start, last))) {
+ map_file = (struct vdpa_map_file *)map->opaque;
+ fput(map_file->file);
+ kfree(map_file);
+ vhost_iotlb_map_free(domain->iotlb, map);
+ }
+}
+
+int vduse_domain_set_map(struct vduse_iova_domain *domain,
+ struct vhost_iotlb *iotlb)
+{
+ struct vdpa_map_file *map_file;
+ struct vhost_iotlb_map *map;
+ u64 start = 0ULL, last = ULLONG_MAX;
+ int ret;
+
+ spin_lock(&domain->iotlb_lock);
+ vduse_iotlb_del_range(domain, start, last);
+
+ for (map = vhost_iotlb_itree_first(iotlb, start, last); map;
+ map = vhost_iotlb_itree_next(map, start, last)) {
+ map_file = (struct vdpa_map_file *)map->opaque;
+ ret = vduse_iotlb_add_range(domain, map->start, map->last,
+ map->addr, map->perm,
+ map_file->file,
+ map_file->offset);
+ if (ret)
+ goto err;
+ }
+ spin_unlock(&domain->iotlb_lock);
+
+ return 0;
+err:
+ vduse_iotlb_del_range(domain, start, last);
+ spin_unlock(&domain->iotlb_lock);
+ return ret;
+}
+
+void vduse_domain_clear_map(struct vduse_iova_domain *domain,
+ struct vhost_iotlb *iotlb)
+{
+ struct vhost_iotlb_map *map;
+ u64 start = 0ULL, last = ULLONG_MAX;
+
+ spin_lock(&domain->iotlb_lock);
+ for (map = vhost_iotlb_itree_first(iotlb, start, last); map;
+ map = vhost_iotlb_itree_next(map, start, last)) {
+ vduse_iotlb_del_range(domain, map->start, map->last);
+ }
+ spin_unlock(&domain->iotlb_lock);
+}
+
+static int vduse_domain_map_bounce_page(struct vduse_iova_domain *domain,
+ u64 iova, u64 size, u64 paddr)
+{
+ struct vduse_bounce_map *map;
+ u64 last = iova + size - 1;
+
+ while (iova <= last) {
+ map = &domain->bounce_maps[iova >> PAGE_SHIFT];
+ if (!map->bounce_page) {
+ map->bounce_page = alloc_page(GFP_ATOMIC);
+ if (!map->bounce_page)
+ return -ENOMEM;
+ }
+ map->orig_phys = paddr;
+ paddr += PAGE_SIZE;
+ iova += PAGE_SIZE;
+ }
+ return 0;
+}
+
+static void vduse_domain_unmap_bounce_page(struct vduse_iova_domain *domain,
+ u64 iova, u64 size)
+{
+ struct vduse_bounce_map *map;
+ u64 last = iova + size - 1;
+
+ while (iova <= last) {
+ map = &domain->bounce_maps[iova >> PAGE_SHIFT];
+ map->orig_phys = INVALID_PHYS_ADDR;
+ iova += PAGE_SIZE;
+ }
+}
+
+static void do_bounce(phys_addr_t orig, void *addr, size_t size,
+ enum dma_data_direction dir)
+{
+ unsigned long pfn = PFN_DOWN(orig);
+ unsigned int offset = offset_in_page(orig);
+ char *buffer;
+ unsigned int sz = 0;
+
+ while (size) {
+ sz = min_t(size_t, PAGE_SIZE - offset, size);
+
+ buffer = kmap_atomic(pfn_to_page(pfn));
+ if (dir == DMA_TO_DEVICE)
+ memcpy(addr, buffer + offset, sz);
+ else
+ memcpy(buffer + offset, addr, sz);
+ kunmap_atomic(buffer);
+
+ size -= sz;
+ pfn++;
+ addr += sz;
+ offset = 0;
+ }
+}
+
+static void vduse_domain_bounce(struct vduse_iova_domain *domain,
+ dma_addr_t iova, size_t size,
+ enum dma_data_direction dir)
+{
+ struct vduse_bounce_map *map;
+ unsigned int offset;
+ void *addr;
+ size_t sz;
+
+ if (iova >= domain->bounce_size)
+ return;
+
+ while (size) {
+ map = &domain->bounce_maps[iova >> PAGE_SHIFT];
+ offset = offset_in_page(iova);
+ sz = min_t(size_t, PAGE_SIZE - offset, size);
+
+ if (WARN_ON(!map->bounce_page ||
+ map->orig_phys == INVALID_PHYS_ADDR))
+ return;
+
+ addr = page_address(map->bounce_page) + offset;
+ do_bounce(map->orig_phys + offset, addr, sz, dir);
+ size -= sz;
+ iova += sz;
+ }
+}
+
+static struct page *
+vduse_domain_get_coherent_page(struct vduse_iova_domain *domain, u64 iova)
+{
+ u64 start = iova & PAGE_MASK;
+ u64 last = start + PAGE_SIZE - 1;
+ struct vhost_iotlb_map *map;
+ struct page *page = NULL;
+
+ spin_lock(&domain->iotlb_lock);
+ map = vhost_iotlb_itree_first(domain->iotlb, start, last);
+ if (!map)
+ goto out;
+
+ page = pfn_to_page((map->addr + iova - map->start) >> PAGE_SHIFT);
+ get_page(page);
+out:
+ spin_unlock(&domain->iotlb_lock);
+
+ return page;
+}
+
+static struct page *
+vduse_domain_get_bounce_page(struct vduse_iova_domain *domain, u64 iova)
+{
+ struct vduse_bounce_map *map;
+ struct page *page = NULL;
+
+ spin_lock(&domain->iotlb_lock);
+ map = &domain->bounce_maps[iova >> PAGE_SHIFT];
+ if (!map->bounce_page)
+ goto out;
+
+ page = map->bounce_page;
+ get_page(page);
+out:
+ spin_unlock(&domain->iotlb_lock);
+
+ return page;
+}
+
+static void
+vduse_domain_free_bounce_pages(struct vduse_iova_domain *domain)
+{
+ struct vduse_bounce_map *map;
+ unsigned long pfn, bounce_pfns;
+
+ bounce_pfns = domain->bounce_size >> PAGE_SHIFT;
+
+ for (pfn = 0; pfn < bounce_pfns; pfn++) {
+ map = &domain->bounce_maps[pfn];
+ if (WARN_ON(map->orig_phys != INVALID_PHYS_ADDR))
+ continue;
+
+ if (!map->bounce_page)
+ continue;
+
+ __free_page(map->bounce_page);
+ map->bounce_page = NULL;
+ }
+}
+
+void vduse_domain_reset_bounce_map(struct vduse_iova_domain *domain)
+{
+ if (!domain->bounce_map)
+ return;
+
+ spin_lock(&domain->iotlb_lock);
+ if (!domain->bounce_map)
+ goto unlock;
+
+ vduse_iotlb_del_range(domain, 0, domain->bounce_size - 1);
+ domain->bounce_map = 0;
+unlock:
+ spin_unlock(&domain->iotlb_lock);
+}
+
+static int vduse_domain_init_bounce_map(struct vduse_iova_domain *domain)
+{
+ int ret = 0;
+
+ if (domain->bounce_map)
+ return 0;
+
+ spin_lock(&domain->iotlb_lock);
+ if (domain->bounce_map)
+ goto unlock;
+
+ ret = vduse_iotlb_add_range(domain, 0, domain->bounce_size - 1,
+ 0, VHOST_MAP_RW, domain->file, 0);
+ if (ret)
+ goto unlock;
+
+ domain->bounce_map = 1;
+unlock:
+ spin_unlock(&domain->iotlb_lock);
+ return ret;
+}
+
+static dma_addr_t
+vduse_domain_alloc_iova(struct iova_domain *iovad,
+ unsigned long size, unsigned long limit)
+{
+ unsigned long shift = iova_shift(iovad);
+ unsigned long iova_len = iova_align(iovad, size) >> shift;
+ unsigned long iova_pfn;
+
+ /*
+ * Freeing non-power-of-two-sized allocations back into the IOVA caches
+ * will come back to bite us badly, so we have to waste a bit of space
+ * rounding up anything cacheable to make sure that can't happen. The
+ * order of the unadjusted size will still match upon freeing.
+ */
+ if (iova_len < (1 << (IOVA_RANGE_CACHE_MAX_SIZE - 1)))
+ iova_len = roundup_pow_of_two(iova_len);
+ iova_pfn = alloc_iova_fast(iovad, iova_len, limit >> shift, true);
+
+ return iova_pfn << shift;
+}
+
+static void vduse_domain_free_iova(struct iova_domain *iovad,
+ dma_addr_t iova, size_t size)
+{
+ unsigned long shift = iova_shift(iovad);
+ unsigned long iova_len = iova_align(iovad, size) >> shift;
+
+ free_iova_fast(iovad, iova >> shift, iova_len);
+}
+
+dma_addr_t vduse_domain_map_page(struct vduse_iova_domain *domain,
+ struct page *page, unsigned long offset,
+ size_t size, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ struct iova_domain *iovad = &domain->stream_iovad;
+ unsigned long limit = domain->bounce_size - 1;
+ phys_addr_t pa = page_to_phys(page) + offset;
+ dma_addr_t iova = vduse_domain_alloc_iova(iovad, size, limit);
+
+ if (!iova)
+ return DMA_MAPPING_ERROR;
+
+ if (vduse_domain_init_bounce_map(domain))
+ goto err;
+
+ if (vduse_domain_map_bounce_page(domain, (u64)iova, (u64)size, pa))
+ goto err;
+
+ if (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)
+ vduse_domain_bounce(domain, iova, size, DMA_TO_DEVICE);
+
+ return iova;
+err:
+ vduse_domain_free_iova(iovad, iova, size);
+ return DMA_MAPPING_ERROR;
+}
+
+void vduse_domain_unmap_page(struct vduse_iova_domain *domain,
+ dma_addr_t dma_addr, size_t size,
+ enum dma_data_direction dir, unsigned long attrs)
+{
+ struct iova_domain *iovad = &domain->stream_iovad;
+
+ if (dir == DMA_FROM_DEVICE || dir == DMA_BIDIRECTIONAL)
+ vduse_domain_bounce(domain, dma_addr, size, DMA_FROM_DEVICE);
+
+ vduse_domain_unmap_bounce_page(domain, (u64)dma_addr, (u64)size);
+ vduse_domain_free_iova(iovad, dma_addr, size);
+}
+
+void *vduse_domain_alloc_coherent(struct vduse_iova_domain *domain,
+ size_t size, dma_addr_t *dma_addr,
+ gfp_t flag, unsigned long attrs)
+{
+ struct iova_domain *iovad = &domain->consistent_iovad;
+ unsigned long limit = domain->iova_limit;
+ dma_addr_t iova = vduse_domain_alloc_iova(iovad, size, limit);
+ void *orig = alloc_pages_exact(size, flag);
+
+ if (!iova || !orig)
+ goto err;
+
+ spin_lock(&domain->iotlb_lock);
+ if (vduse_iotlb_add_range(domain, (u64)iova, (u64)iova + size - 1,
+ virt_to_phys(orig), VHOST_MAP_RW,
+ domain->file, (u64)iova)) {
+ spin_unlock(&domain->iotlb_lock);
+ goto err;
+ }
+ spin_unlock(&domain->iotlb_lock);
+
+ *dma_addr = iova;
+
+ return orig;
+err:
+ *dma_addr = DMA_MAPPING_ERROR;
+ if (orig)
+ free_pages_exact(orig, size);
+ if (iova)
+ vduse_domain_free_iova(iovad, iova, size);
+
+ return NULL;
+}
+
+void vduse_domain_free_coherent(struct vduse_iova_domain *domain, size_t size,
+ void *vaddr, dma_addr_t dma_addr,
+ unsigned long attrs)
+{
+ struct iova_domain *iovad = &domain->consistent_iovad;
+ struct vhost_iotlb_map *map;
+ struct vdpa_map_file *map_file;
+ phys_addr_t pa;
+
+ spin_lock(&domain->iotlb_lock);
+ map = vhost_iotlb_itree_first(domain->iotlb, (u64)dma_addr,
+ (u64)dma_addr + size - 1);
+ if (WARN_ON(!map)) {
+ spin_unlock(&domain->iotlb_lock);
+ return;
+ }
+ map_file = (struct vdpa_map_file *)map->opaque;
+ fput(map_file->file);
+ kfree(map_file);
+ pa = map->addr;
+ vhost_iotlb_map_free(domain->iotlb, map);
+ spin_unlock(&domain->iotlb_lock);
+
+ vduse_domain_free_iova(iovad, dma_addr, size);
+ free_pages_exact(phys_to_virt(pa), size);
+}
+
+static vm_fault_t vduse_domain_mmap_fault(struct vm_fault *vmf)
+{
+ struct vduse_iova_domain *domain = vmf->vma->vm_private_data;
+ unsigned long iova = vmf->pgoff << PAGE_SHIFT;
+ struct page *page;
+
+ if (!domain)
+ return VM_FAULT_SIGBUS;
+
+ if (iova < domain->bounce_size)
+ page = vduse_domain_get_bounce_page(domain, iova);
+ else
+ page = vduse_domain_get_coherent_page(domain, iova);
+
+ if (!page)
+ return VM_FAULT_SIGBUS;
+
+ vmf->page = page;
+
+ return 0;
+}
+
+static const struct vm_operations_struct vduse_domain_mmap_ops = {
+ .fault = vduse_domain_mmap_fault,
+};
+
+static int vduse_domain_mmap(struct file *file, struct vm_area_struct *vma)
+{
+ struct vduse_iova_domain *domain = file->private_data;
+
+ vma->vm_flags |= VM_DONTDUMP | VM_DONTEXPAND;
+ vma->vm_private_data = domain;
+ vma->vm_ops = &vduse_domain_mmap_ops;
+
+ return 0;
+}
+
+static int vduse_domain_release(struct inode *inode, struct file *file)
+{
+ struct vduse_iova_domain *domain = file->private_data;
+
+ spin_lock(&domain->iotlb_lock);
+ vduse_iotlb_del_range(domain, 0, ULLONG_MAX);
+ vduse_domain_free_bounce_pages(domain);
+ spin_unlock(&domain->iotlb_lock);
+ put_iova_domain(&domain->stream_iovad);
+ put_iova_domain(&domain->consistent_iovad);
+ vhost_iotlb_free(domain->iotlb);
+ vfree(domain->bounce_maps);
+ kfree(domain);
+
+ return 0;
+}
+
+static const struct file_operations vduse_domain_fops = {
+ .owner = THIS_MODULE,
+ .mmap = vduse_domain_mmap,
+ .release = vduse_domain_release,
+};
+
+void vduse_domain_destroy(struct vduse_iova_domain *domain)
+{
+ fput(domain->file);
+}
+
+struct vduse_iova_domain *
+vduse_domain_create(unsigned long iova_limit, size_t bounce_size)
+{
+ struct vduse_iova_domain *domain;
+ struct file *file;
+ struct vduse_bounce_map *map;
+ unsigned long pfn, bounce_pfns;
+
+ bounce_pfns = PAGE_ALIGN(bounce_size) >> PAGE_SHIFT;
+ if (iova_limit <= bounce_size)
+ return NULL;
+
+ domain = kzalloc(sizeof(*domain), GFP_KERNEL);
+ if (!domain)
+ return NULL;
+
+ domain->iotlb = vhost_iotlb_alloc(0, 0);
+ if (!domain->iotlb)
+ goto err_iotlb;
+
+ domain->iova_limit = iova_limit;
+ domain->bounce_size = PAGE_ALIGN(bounce_size);
+ domain->bounce_maps = vzalloc(bounce_pfns *
+ sizeof(struct vduse_bounce_map));
+ if (!domain->bounce_maps)
+ goto err_map;
+
+ for (pfn = 0; pfn < bounce_pfns; pfn++) {
+ map = &domain->bounce_maps[pfn];
+ map->orig_phys = INVALID_PHYS_ADDR;
+ }
+ file = anon_inode_getfile("[vduse-domain]", &vduse_domain_fops,
+ domain, O_RDWR);
+ if (IS_ERR(file))
+ goto err_file;
+
+ domain->file = file;
+ spin_lock_init(&domain->iotlb_lock);
+ init_iova_domain(&domain->stream_iovad,
+ PAGE_SIZE, IOVA_START_PFN);
+ init_iova_domain(&domain->consistent_iovad,
+ PAGE_SIZE, bounce_pfns);
+
+ return domain;
+err_file:
+ vfree(domain->bounce_maps);
+err_map:
+ vhost_iotlb_free(domain->iotlb);
+err_iotlb:
+ kfree(domain);
+ return NULL;
+}
+
+int vduse_domain_init(void)
+{
+ return iova_cache_get();
+}
+
+void vduse_domain_exit(void)
+{
+ iova_cache_put();
+}
diff --git a/drivers/vdpa/vdpa_user/iova_domain.h b/drivers/vdpa/vdpa_user/iova_domain.h
new file mode 100644
index 000000000000..2722d9b8e21a
--- /dev/null
+++ b/drivers/vdpa/vdpa_user/iova_domain.h
@@ -0,0 +1,73 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * MMU-based software IOTLB.
+ *
+ * Copyright (C) 2020-2021 Bytedance Inc. and/or its affiliates. All rights reserved.
+ *
+ * Author: Xie Yongji <xieyongji@bytedance.com>
+ *
+ */
+
+#ifndef _VDUSE_IOVA_DOMAIN_H
+#define _VDUSE_IOVA_DOMAIN_H
+
+#include <linux/iova.h>
+#include <linux/dma-mapping.h>
+#include <linux/vhost_iotlb.h>
+
+#define IOVA_START_PFN 1
+
+#define INVALID_PHYS_ADDR (~(phys_addr_t)0)
+
+struct vduse_bounce_map {
+ struct page *bounce_page;
+ u64 orig_phys;
+};
+
+struct vduse_iova_domain {
+ struct iova_domain stream_iovad;
+ struct iova_domain consistent_iovad;
+ struct vduse_bounce_map *bounce_maps;
+ size_t bounce_size;
+ unsigned long iova_limit;
+ int bounce_map;
+ struct vhost_iotlb *iotlb;
+ spinlock_t iotlb_lock;
+ struct file *file;
+};
+
+int vduse_domain_set_map(struct vduse_iova_domain *domain,
+ struct vhost_iotlb *iotlb);
+
+void vduse_domain_clear_map(struct vduse_iova_domain *domain,
+ struct vhost_iotlb *iotlb);
+
+dma_addr_t vduse_domain_map_page(struct vduse_iova_domain *domain,
+ struct page *page, unsigned long offset,
+ size_t size, enum dma_data_direction dir,
+ unsigned long attrs);
+
+void vduse_domain_unmap_page(struct vduse_iova_domain *domain,
+ dma_addr_t dma_addr, size_t size,
+ enum dma_data_direction dir, unsigned long attrs);
+
+void *vduse_domain_alloc_coherent(struct vduse_iova_domain *domain,
+ size_t size, dma_addr_t *dma_addr,
+ gfp_t flag, unsigned long attrs);
+
+void vduse_domain_free_coherent(struct vduse_iova_domain *domain, size_t size,
+ void *vaddr, dma_addr_t dma_addr,
+ unsigned long attrs);
+
+void vduse_domain_reset_bounce_map(struct vduse_iova_domain *domain);
+
+void vduse_domain_destroy(struct vduse_iova_domain *domain);
+
+struct vduse_iova_domain *vduse_domain_create(unsigned long iova_limit,
+ size_t bounce_size);
+
+int vduse_domain_init(void);
+
+void vduse_domain_exit(void);
+
+#endif /* _VDUSE_IOVA_DOMAIN_H */
--
2.11.0
^ permalink raw reply related [flat|nested] 55+ messages in thread* [PATCH v10 16/17] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-07-29 7:34 [PATCH v10 00/17] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (14 preceding siblings ...)
2021-07-29 7:35 ` [PATCH v10 15/17] vduse: Implement an MMU-based software IOTLB Xie Yongji
@ 2021-07-29 7:35 ` Xie Yongji
2021-07-29 9:00 ` Greg KH
2021-08-03 7:30 ` Jason Wang
2021-07-29 7:35 ` [PATCH v10 17/17] Documentation: Add documentation for VDUSE Xie Yongji
16 siblings, 2 replies; 55+ messages in thread
From: Xie Yongji @ 2021-07-29 7:35 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu, joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
This VDUSE driver enables implementing software-emulated vDPA
devices in userspace. The vDPA device is created by
ioctl(VDUSE_CREATE_DEV) on /dev/vduse/control. Then a char device
interface (/dev/vduse/$NAME) is exported to userspace for device
emulation.
In order to make the device emulation more secure, the device's
control path is handled in kernel. A message mechnism is introduced
to forward some dataplane related control messages to userspace.
And in the data path, the DMA buffer will be mapped into userspace
address space through different ways depending on the vDPA bus to
which the vDPA device is attached. In virtio-vdpa case, the MMU-based
software IOTLB is used to achieve that. And in vhost-vdpa case, the
DMA buffer is reside in a userspace memory region which can be shared
to the VDUSE userspace processs via transferring the shmfd.
For more details on VDUSE design and usage, please see the follow-on
Documentation commit.
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
---
Documentation/userspace-api/ioctl/ioctl-number.rst | 1 +
drivers/vdpa/Kconfig | 10 +
drivers/vdpa/Makefile | 1 +
drivers/vdpa/vdpa_user/Makefile | 5 +
drivers/vdpa/vdpa_user/vduse_dev.c | 1541 ++++++++++++++++++++
include/uapi/linux/vduse.h | 220 +++
6 files changed, 1778 insertions(+)
create mode 100644 drivers/vdpa/vdpa_user/Makefile
create mode 100644 drivers/vdpa/vdpa_user/vduse_dev.c
create mode 100644 include/uapi/linux/vduse.h
diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst
index 1409e40e6345..293ca3aef358 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -300,6 +300,7 @@ Code Seq# Include File Comments
'z' 10-4F drivers/s390/crypto/zcrypt_api.h conflict!
'|' 00-7F linux/media.h
0x80 00-1F linux/fb.h
+0x81 00-1F linux/vduse.h
0x89 00-06 arch/x86/include/asm/sockios.h
0x89 0B-DF linux/sockios.h
0x89 E0-EF linux/sockios.h SIOCPROTOPRIVATE range
diff --git a/drivers/vdpa/Kconfig b/drivers/vdpa/Kconfig
index a503c1b2bfd9..6e23bce6433a 100644
--- a/drivers/vdpa/Kconfig
+++ b/drivers/vdpa/Kconfig
@@ -33,6 +33,16 @@ config VDPA_SIM_BLOCK
vDPA block device simulator which terminates IO request in a
memory buffer.
+config VDPA_USER
+ tristate "VDUSE (vDPA Device in Userspace) support"
+ depends on EVENTFD && MMU && HAS_DMA
+ select DMA_OPS
+ select VHOST_IOTLB
+ select IOMMU_IOVA
+ help
+ With VDUSE it is possible to emulate a vDPA Device
+ in a userspace program.
+
config IFCVF
tristate "Intel IFC VF vDPA driver"
depends on PCI_MSI
diff --git a/drivers/vdpa/Makefile b/drivers/vdpa/Makefile
index 67fe7f3d6943..f02ebed33f19 100644
--- a/drivers/vdpa/Makefile
+++ b/drivers/vdpa/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_VDPA) += vdpa.o
obj-$(CONFIG_VDPA_SIM) += vdpa_sim/
+obj-$(CONFIG_VDPA_USER) += vdpa_user/
obj-$(CONFIG_IFCVF) += ifcvf/
obj-$(CONFIG_MLX5_VDPA) += mlx5/
obj-$(CONFIG_VP_VDPA) += virtio_pci/
diff --git a/drivers/vdpa/vdpa_user/Makefile b/drivers/vdpa/vdpa_user/Makefile
new file mode 100644
index 000000000000..260e0b26af99
--- /dev/null
+++ b/drivers/vdpa/vdpa_user/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+
+vduse-y := vduse_dev.o iova_domain.o
+
+obj-$(CONFIG_VDPA_USER) += vduse.o
diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
new file mode 100644
index 000000000000..6addc62e7de6
--- /dev/null
+++ b/drivers/vdpa/vdpa_user/vduse_dev.c
@@ -0,0 +1,1541 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * VDUSE: vDPA Device in Userspace
+ *
+ * Copyright (C) 2020-2021 Bytedance Inc. and/or its affiliates. All rights reserved.
+ *
+ * Author: Xie Yongji <xieyongji@bytedance.com>
+ *
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/cdev.h>
+#include <linux/device.h>
+#include <linux/eventfd.h>
+#include <linux/slab.h>
+#include <linux/wait.h>
+#include <linux/dma-map-ops.h>
+#include <linux/poll.h>
+#include <linux/file.h>
+#include <linux/uio.h>
+#include <linux/vdpa.h>
+#include <linux/nospec.h>
+#include <uapi/linux/vduse.h>
+#include <uapi/linux/vdpa.h>
+#include <uapi/linux/virtio_config.h>
+#include <uapi/linux/virtio_ids.h>
+#include <uapi/linux/virtio_blk.h>
+#include <linux/mod_devicetable.h>
+
+#include "iova_domain.h"
+
+#define DRV_AUTHOR "Yongji Xie <xieyongji@bytedance.com>"
+#define DRV_DESC "vDPA Device in Userspace"
+#define DRV_LICENSE "GPL v2"
+
+#define VDUSE_DEV_MAX (1U << MINORBITS)
+#define VDUSE_BOUNCE_SIZE (64 * 1024 * 1024)
+#define VDUSE_IOVA_SIZE (128 * 1024 * 1024)
+#define VDUSE_REQUEST_TIMEOUT 30
+
+struct vduse_virtqueue {
+ u16 index;
+ u16 num_max;
+ u32 num;
+ u64 desc_addr;
+ u64 driver_addr;
+ u64 device_addr;
+ struct vdpa_vq_state state;
+ bool ready;
+ bool kicked;
+ spinlock_t kick_lock;
+ spinlock_t irq_lock;
+ struct eventfd_ctx *kickfd;
+ struct vdpa_callback cb;
+ struct work_struct inject;
+};
+
+struct vduse_dev;
+
+struct vduse_vdpa {
+ struct vdpa_device vdpa;
+ struct vduse_dev *dev;
+};
+
+struct vduse_dev {
+ struct vduse_vdpa *vdev;
+ struct device *dev;
+ struct vduse_virtqueue *vqs;
+ struct vduse_iova_domain *domain;
+ char *name;
+ struct mutex lock;
+ spinlock_t msg_lock;
+ u64 msg_unique;
+ wait_queue_head_t waitq;
+ struct list_head send_list;
+ struct list_head recv_list;
+ struct vdpa_callback config_cb;
+ struct work_struct inject;
+ spinlock_t irq_lock;
+ int minor;
+ bool broken;
+ bool connected;
+ u64 api_version;
+ u64 device_features;
+ u64 driver_features;
+ u32 device_id;
+ u32 vendor_id;
+ u32 generation;
+ u32 config_size;
+ void *config;
+ u8 status;
+ u32 vq_num;
+ u32 vq_align;
+};
+
+struct vduse_dev_msg {
+ struct vduse_dev_request req;
+ struct vduse_dev_response resp;
+ struct list_head list;
+ wait_queue_head_t waitq;
+ bool completed;
+};
+
+struct vduse_control {
+ u64 api_version;
+};
+
+static DEFINE_MUTEX(vduse_lock);
+static DEFINE_IDR(vduse_idr);
+
+static dev_t vduse_major;
+static struct class *vduse_class;
+static struct cdev vduse_ctrl_cdev;
+static struct cdev vduse_cdev;
+static struct workqueue_struct *vduse_irq_wq;
+
+static u32 allowed_device_id[] = {
+ VIRTIO_ID_BLOCK,
+};
+
+static inline struct vduse_dev *vdpa_to_vduse(struct vdpa_device *vdpa)
+{
+ struct vduse_vdpa *vdev = container_of(vdpa, struct vduse_vdpa, vdpa);
+
+ return vdev->dev;
+}
+
+static inline struct vduse_dev *dev_to_vduse(struct device *dev)
+{
+ struct vdpa_device *vdpa = dev_to_vdpa(dev);
+
+ return vdpa_to_vduse(vdpa);
+}
+
+static struct vduse_dev_msg *vduse_find_msg(struct list_head *head,
+ uint32_t request_id)
+{
+ struct vduse_dev_msg *msg;
+
+ list_for_each_entry(msg, head, list) {
+ if (msg->req.request_id == request_id) {
+ list_del(&msg->list);
+ return msg;
+ }
+ }
+
+ return NULL;
+}
+
+static struct vduse_dev_msg *vduse_dequeue_msg(struct list_head *head)
+{
+ struct vduse_dev_msg *msg = NULL;
+
+ if (!list_empty(head)) {
+ msg = list_first_entry(head, struct vduse_dev_msg, list);
+ list_del(&msg->list);
+ }
+
+ return msg;
+}
+
+static void vduse_enqueue_msg(struct list_head *head,
+ struct vduse_dev_msg *msg)
+{
+ list_add_tail(&msg->list, head);
+}
+
+static void vduse_dev_broken(struct vduse_dev *dev)
+{
+ struct vduse_dev_msg *msg, *tmp;
+
+ if (unlikely(dev->broken))
+ return;
+
+ list_splice_init(&dev->recv_list, &dev->send_list);
+ list_for_each_entry_safe(msg, tmp, &dev->send_list, list) {
+ list_del(&msg->list);
+ msg->completed = 1;
+ msg->resp.result = VDUSE_REQ_RESULT_FAILED;
+ wake_up(&msg->waitq);
+ }
+ dev->broken = true;
+ wake_up(&dev->waitq);
+}
+
+static int vduse_dev_msg_sync(struct vduse_dev *dev,
+ struct vduse_dev_msg *msg)
+{
+ int ret;
+
+ if (unlikely(dev->broken))
+ return -EIO;
+
+ init_waitqueue_head(&msg->waitq);
+ spin_lock(&dev->msg_lock);
+ if (unlikely(dev->broken)) {
+ spin_unlock(&dev->msg_lock);
+ return -EIO;
+ }
+ msg->req.request_id = dev->msg_unique++;
+ vduse_enqueue_msg(&dev->send_list, msg);
+ wake_up(&dev->waitq);
+ spin_unlock(&dev->msg_lock);
+
+ ret = wait_event_killable_timeout(msg->waitq, msg->completed,
+ VDUSE_REQUEST_TIMEOUT * HZ);
+ spin_lock(&dev->msg_lock);
+ if (!msg->completed) {
+ list_del(&msg->list);
+ msg->resp.result = VDUSE_REQ_RESULT_FAILED;
+ /* Mark the device as malfunction when there is a timeout */
+ if (!ret)
+ vduse_dev_broken(dev);
+ }
+ ret = (msg->resp.result == VDUSE_REQ_RESULT_OK) ? 0 : -EIO;
+ spin_unlock(&dev->msg_lock);
+
+ return ret;
+}
+
+static int vduse_dev_get_vq_state_packed(struct vduse_dev *dev,
+ struct vduse_virtqueue *vq,
+ struct vdpa_vq_state_packed *packed)
+{
+ struct vduse_dev_msg msg = { 0 };
+ int ret;
+
+ msg.req.type = VDUSE_GET_VQ_STATE;
+ msg.req.vq_state.index = vq->index;
+
+ ret = vduse_dev_msg_sync(dev, &msg);
+ if (ret)
+ return ret;
+
+ packed->last_avail_counter =
+ msg.resp.vq_state.packed.last_avail_counter;
+ packed->last_avail_idx = msg.resp.vq_state.packed.last_avail_idx;
+ packed->last_used_counter = msg.resp.vq_state.packed.last_used_counter;
+ packed->last_used_idx = msg.resp.vq_state.packed.last_used_idx;
+
+ return 0;
+}
+
+static int vduse_dev_get_vq_state_split(struct vduse_dev *dev,
+ struct vduse_virtqueue *vq,
+ struct vdpa_vq_state_split *split)
+{
+ struct vduse_dev_msg msg = { 0 };
+ int ret;
+
+ msg.req.type = VDUSE_GET_VQ_STATE;
+ msg.req.vq_state.index = vq->index;
+
+ ret = vduse_dev_msg_sync(dev, &msg);
+ if (ret)
+ return ret;
+
+ split->avail_index = msg.resp.vq_state.split.avail_index;
+
+ return 0;
+}
+
+static int vduse_dev_set_status(struct vduse_dev *dev, u8 status)
+{
+ struct vduse_dev_msg msg = { 0 };
+
+ msg.req.type = VDUSE_SET_STATUS;
+ msg.req.s.status = status;
+
+ return vduse_dev_msg_sync(dev, &msg);
+}
+
+static int vduse_dev_update_iotlb(struct vduse_dev *dev,
+ u64 start, u64 last)
+{
+ struct vduse_dev_msg msg = { 0 };
+
+ if (last < start)
+ return -EINVAL;
+
+ msg.req.type = VDUSE_UPDATE_IOTLB;
+ msg.req.iova.start = start;
+ msg.req.iova.last = last;
+
+ return vduse_dev_msg_sync(dev, &msg);
+}
+
+static ssize_t vduse_dev_read_iter(struct kiocb *iocb, struct iov_iter *to)
+{
+ struct file *file = iocb->ki_filp;
+ struct vduse_dev *dev = file->private_data;
+ struct vduse_dev_msg *msg;
+ int size = sizeof(struct vduse_dev_request);
+ ssize_t ret;
+
+ if (iov_iter_count(to) < size)
+ return -EINVAL;
+
+ spin_lock(&dev->msg_lock);
+ while (1) {
+ msg = vduse_dequeue_msg(&dev->send_list);
+ if (msg)
+ break;
+
+ ret = -EAGAIN;
+ if (file->f_flags & O_NONBLOCK)
+ goto unlock;
+
+ spin_unlock(&dev->msg_lock);
+ ret = wait_event_interruptible_exclusive(dev->waitq,
+ !list_empty(&dev->send_list));
+ if (ret)
+ return ret;
+
+ spin_lock(&dev->msg_lock);
+ }
+ spin_unlock(&dev->msg_lock);
+ ret = copy_to_iter(&msg->req, size, to);
+ spin_lock(&dev->msg_lock);
+ if (ret != size) {
+ ret = -EFAULT;
+ vduse_enqueue_msg(&dev->send_list, msg);
+ goto unlock;
+ }
+ vduse_enqueue_msg(&dev->recv_list, msg);
+unlock:
+ spin_unlock(&dev->msg_lock);
+
+ return ret;
+}
+
+static ssize_t vduse_dev_write_iter(struct kiocb *iocb, struct iov_iter *from)
+{
+ struct file *file = iocb->ki_filp;
+ struct vduse_dev *dev = file->private_data;
+ struct vduse_dev_response resp;
+ struct vduse_dev_msg *msg;
+ size_t ret;
+
+ ret = copy_from_iter(&resp, sizeof(resp), from);
+ if (ret != sizeof(resp))
+ return -EINVAL;
+
+ spin_lock(&dev->msg_lock);
+ msg = vduse_find_msg(&dev->recv_list, resp.request_id);
+ if (!msg) {
+ ret = -ENOENT;
+ goto unlock;
+ }
+
+ memcpy(&msg->resp, &resp, sizeof(resp));
+ msg->completed = 1;
+ wake_up(&msg->waitq);
+unlock:
+ spin_unlock(&dev->msg_lock);
+
+ return ret;
+}
+
+static __poll_t vduse_dev_poll(struct file *file, poll_table *wait)
+{
+ struct vduse_dev *dev = file->private_data;
+ __poll_t mask = 0;
+
+ poll_wait(file, &dev->waitq, wait);
+
+ spin_lock(&dev->msg_lock);
+
+ if (unlikely(dev->broken))
+ mask |= EPOLLERR;
+ if (!list_empty(&dev->send_list))
+ mask |= EPOLLIN | EPOLLRDNORM;
+ if (!list_empty(&dev->recv_list))
+ mask |= EPOLLOUT | EPOLLWRNORM;
+
+ spin_unlock(&dev->msg_lock);
+
+ return mask;
+}
+
+static void vduse_dev_reset(struct vduse_dev *dev)
+{
+ int i;
+ struct vduse_iova_domain *domain = dev->domain;
+
+ /* The coherent mappings are handled in vduse_dev_free_coherent() */
+ if (domain->bounce_map)
+ vduse_domain_reset_bounce_map(domain);
+
+ dev->driver_features = 0;
+ dev->generation++;
+ spin_lock(&dev->irq_lock);
+ dev->config_cb.callback = NULL;
+ dev->config_cb.private = NULL;
+ spin_unlock(&dev->irq_lock);
+ flush_work(&dev->inject);
+
+ for (i = 0; i < dev->vq_num; i++) {
+ struct vduse_virtqueue *vq = &dev->vqs[i];
+
+ vq->ready = false;
+ vq->desc_addr = 0;
+ vq->driver_addr = 0;
+ vq->device_addr = 0;
+ vq->num = 0;
+ memset(&vq->state, 0, sizeof(vq->state));
+
+ spin_lock(&vq->kick_lock);
+ vq->kicked = false;
+ if (vq->kickfd)
+ eventfd_ctx_put(vq->kickfd);
+ vq->kickfd = NULL;
+ spin_unlock(&vq->kick_lock);
+
+ spin_lock(&vq->irq_lock);
+ vq->cb.callback = NULL;
+ vq->cb.private = NULL;
+ spin_unlock(&vq->irq_lock);
+ flush_work(&vq->inject);
+ }
+}
+
+static int vduse_vdpa_set_vq_address(struct vdpa_device *vdpa, u16 idx,
+ u64 desc_area, u64 driver_area,
+ u64 device_area)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+ struct vduse_virtqueue *vq = &dev->vqs[idx];
+
+ vq->desc_addr = desc_area;
+ vq->driver_addr = driver_area;
+ vq->device_addr = device_area;
+
+ return 0;
+}
+
+static void vduse_vdpa_kick_vq(struct vdpa_device *vdpa, u16 idx)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+ struct vduse_virtqueue *vq = &dev->vqs[idx];
+
+ spin_lock(&vq->kick_lock);
+ if (!vq->ready)
+ goto unlock;
+
+ if (vq->kickfd)
+ eventfd_signal(vq->kickfd, 1);
+ else
+ vq->kicked = true;
+unlock:
+ spin_unlock(&vq->kick_lock);
+}
+
+static void vduse_vdpa_set_vq_cb(struct vdpa_device *vdpa, u16 idx,
+ struct vdpa_callback *cb)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+ struct vduse_virtqueue *vq = &dev->vqs[idx];
+
+ spin_lock(&vq->irq_lock);
+ vq->cb.callback = cb->callback;
+ vq->cb.private = cb->private;
+ spin_unlock(&vq->irq_lock);
+}
+
+static void vduse_vdpa_set_vq_num(struct vdpa_device *vdpa, u16 idx, u32 num)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+ struct vduse_virtqueue *vq = &dev->vqs[idx];
+
+ vq->num = num;
+}
+
+static void vduse_vdpa_set_vq_ready(struct vdpa_device *vdpa,
+ u16 idx, bool ready)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+ struct vduse_virtqueue *vq = &dev->vqs[idx];
+
+ vq->ready = ready;
+}
+
+static bool vduse_vdpa_get_vq_ready(struct vdpa_device *vdpa, u16 idx)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+ struct vduse_virtqueue *vq = &dev->vqs[idx];
+
+ return vq->ready;
+}
+
+static int vduse_vdpa_set_vq_state(struct vdpa_device *vdpa, u16 idx,
+ const struct vdpa_vq_state *state)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+ struct vduse_virtqueue *vq = &dev->vqs[idx];
+
+ if (dev->driver_features & BIT_ULL(VIRTIO_F_RING_PACKED)) {
+ vq->state.packed.last_avail_counter =
+ state->packed.last_avail_counter;
+ vq->state.packed.last_avail_idx = state->packed.last_avail_idx;
+ vq->state.packed.last_used_counter =
+ state->packed.last_used_counter;
+ vq->state.packed.last_used_idx = state->packed.last_used_idx;
+ } else
+ vq->state.split.avail_index = state->split.avail_index;
+
+ return 0;
+}
+
+static int vduse_vdpa_get_vq_state(struct vdpa_device *vdpa, u16 idx,
+ struct vdpa_vq_state *state)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+ struct vduse_virtqueue *vq = &dev->vqs[idx];
+
+ if (dev->driver_features & BIT_ULL(VIRTIO_F_RING_PACKED))
+ return vduse_dev_get_vq_state_packed(dev, vq, &state->packed);
+
+ return vduse_dev_get_vq_state_split(dev, vq, &state->split);
+}
+
+static u32 vduse_vdpa_get_vq_align(struct vdpa_device *vdpa)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ return dev->vq_align;
+}
+
+static u64 vduse_vdpa_get_features(struct vdpa_device *vdpa)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ return dev->device_features;
+}
+
+static int vduse_vdpa_set_features(struct vdpa_device *vdpa, u64 features)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ dev->driver_features = features;
+ return 0;
+}
+
+static void vduse_vdpa_set_config_cb(struct vdpa_device *vdpa,
+ struct vdpa_callback *cb)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ spin_lock(&dev->irq_lock);
+ dev->config_cb.callback = cb->callback;
+ dev->config_cb.private = cb->private;
+ spin_unlock(&dev->irq_lock);
+}
+
+static u16 vduse_vdpa_get_vq_num_max(struct vdpa_device *vdpa, u16 idx)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ return dev->vqs[idx].num_max;
+}
+
+static u32 vduse_vdpa_get_device_id(struct vdpa_device *vdpa)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ return dev->device_id;
+}
+
+static u32 vduse_vdpa_get_vendor_id(struct vdpa_device *vdpa)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ return dev->vendor_id;
+}
+
+static u8 vduse_vdpa_get_status(struct vdpa_device *vdpa)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ return dev->status;
+}
+
+static void vduse_vdpa_set_status(struct vdpa_device *vdpa, u8 status)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ if (vduse_dev_set_status(dev, status))
+ return;
+
+ dev->status = status;
+ if (status == 0)
+ vduse_dev_reset(dev);
+}
+
+static size_t vduse_vdpa_get_config_size(struct vdpa_device *vdpa)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ return dev->config_size;
+}
+
+static void vduse_vdpa_get_config(struct vdpa_device *vdpa, unsigned int offset,
+ void *buf, unsigned int len)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ if (len > dev->config_size - offset)
+ return;
+
+ memcpy(buf, dev->config + offset, len);
+}
+
+static void vduse_vdpa_set_config(struct vdpa_device *vdpa, unsigned int offset,
+ const void *buf, unsigned int len)
+{
+ /* Now we only support read-only configuration space */
+}
+
+static u32 vduse_vdpa_get_generation(struct vdpa_device *vdpa)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ return dev->generation;
+}
+
+static int vduse_vdpa_set_map(struct vdpa_device *vdpa,
+ struct vhost_iotlb *iotlb)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+ int ret;
+
+ ret = vduse_domain_set_map(dev->domain, iotlb);
+ if (ret)
+ return ret;
+
+ ret = vduse_dev_update_iotlb(dev, 0ULL, ULLONG_MAX);
+ if (ret) {
+ vduse_domain_clear_map(dev->domain, iotlb);
+ return ret;
+ }
+
+ return 0;
+}
+
+static void vduse_vdpa_free(struct vdpa_device *vdpa)
+{
+ struct vduse_dev *dev = vdpa_to_vduse(vdpa);
+
+ dev->vdev = NULL;
+}
+
+static const struct vdpa_config_ops vduse_vdpa_config_ops = {
+ .set_vq_address = vduse_vdpa_set_vq_address,
+ .kick_vq = vduse_vdpa_kick_vq,
+ .set_vq_cb = vduse_vdpa_set_vq_cb,
+ .set_vq_num = vduse_vdpa_set_vq_num,
+ .set_vq_ready = vduse_vdpa_set_vq_ready,
+ .get_vq_ready = vduse_vdpa_get_vq_ready,
+ .set_vq_state = vduse_vdpa_set_vq_state,
+ .get_vq_state = vduse_vdpa_get_vq_state,
+ .get_vq_align = vduse_vdpa_get_vq_align,
+ .get_features = vduse_vdpa_get_features,
+ .set_features = vduse_vdpa_set_features,
+ .set_config_cb = vduse_vdpa_set_config_cb,
+ .get_vq_num_max = vduse_vdpa_get_vq_num_max,
+ .get_device_id = vduse_vdpa_get_device_id,
+ .get_vendor_id = vduse_vdpa_get_vendor_id,
+ .get_status = vduse_vdpa_get_status,
+ .set_status = vduse_vdpa_set_status,
+ .get_config_size = vduse_vdpa_get_config_size,
+ .get_config = vduse_vdpa_get_config,
+ .set_config = vduse_vdpa_set_config,
+ .get_generation = vduse_vdpa_get_generation,
+ .set_map = vduse_vdpa_set_map,
+ .free = vduse_vdpa_free,
+};
+
+static dma_addr_t vduse_dev_map_page(struct device *dev, struct page *page,
+ unsigned long offset, size_t size,
+ enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ struct vduse_dev *vdev = dev_to_vduse(dev);
+ struct vduse_iova_domain *domain = vdev->domain;
+
+ return vduse_domain_map_page(domain, page, offset, size, dir, attrs);
+}
+
+static void vduse_dev_unmap_page(struct device *dev, dma_addr_t dma_addr,
+ size_t size, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ struct vduse_dev *vdev = dev_to_vduse(dev);
+ struct vduse_iova_domain *domain = vdev->domain;
+
+ return vduse_domain_unmap_page(domain, dma_addr, size, dir, attrs);
+}
+
+static void *vduse_dev_alloc_coherent(struct device *dev, size_t size,
+ dma_addr_t *dma_addr, gfp_t flag,
+ unsigned long attrs)
+{
+ struct vduse_dev *vdev = dev_to_vduse(dev);
+ struct vduse_iova_domain *domain = vdev->domain;
+ unsigned long iova;
+ void *addr;
+
+ *dma_addr = DMA_MAPPING_ERROR;
+ addr = vduse_domain_alloc_coherent(domain, size,
+ (dma_addr_t *)&iova, flag, attrs);
+ if (!addr)
+ return NULL;
+
+ *dma_addr = (dma_addr_t)iova;
+
+ return addr;
+}
+
+static void vduse_dev_free_coherent(struct device *dev, size_t size,
+ void *vaddr, dma_addr_t dma_addr,
+ unsigned long attrs)
+{
+ struct vduse_dev *vdev = dev_to_vduse(dev);
+ struct vduse_iova_domain *domain = vdev->domain;
+
+ vduse_domain_free_coherent(domain, size, vaddr, dma_addr, attrs);
+}
+
+static size_t vduse_dev_max_mapping_size(struct device *dev)
+{
+ struct vduse_dev *vdev = dev_to_vduse(dev);
+ struct vduse_iova_domain *domain = vdev->domain;
+
+ return domain->bounce_size;
+}
+
+static const struct dma_map_ops vduse_dev_dma_ops = {
+ .map_page = vduse_dev_map_page,
+ .unmap_page = vduse_dev_unmap_page,
+ .alloc = vduse_dev_alloc_coherent,
+ .free = vduse_dev_free_coherent,
+ .max_mapping_size = vduse_dev_max_mapping_size,
+};
+
+static unsigned int perm_to_file_flags(u8 perm)
+{
+ unsigned int flags = 0;
+
+ switch (perm) {
+ case VDUSE_ACCESS_WO:
+ flags |= O_WRONLY;
+ break;
+ case VDUSE_ACCESS_RO:
+ flags |= O_RDONLY;
+ break;
+ case VDUSE_ACCESS_RW:
+ flags |= O_RDWR;
+ break;
+ default:
+ WARN(1, "invalidate vhost IOTLB permission\n");
+ break;
+ }
+
+ return flags;
+}
+
+static int vduse_kickfd_setup(struct vduse_dev *dev,
+ struct vduse_vq_eventfd *eventfd)
+{
+ struct eventfd_ctx *ctx = NULL;
+ struct vduse_virtqueue *vq;
+ u32 index;
+
+ if (eventfd->index >= dev->vq_num)
+ return -EINVAL;
+
+ index = array_index_nospec(eventfd->index, dev->vq_num);
+ vq = &dev->vqs[index];
+ if (eventfd->fd >= 0) {
+ ctx = eventfd_ctx_fdget(eventfd->fd);
+ if (IS_ERR(ctx))
+ return PTR_ERR(ctx);
+ } else if (eventfd->fd != VDUSE_EVENTFD_DEASSIGN)
+ return 0;
+
+ spin_lock(&vq->kick_lock);
+ if (vq->kickfd)
+ eventfd_ctx_put(vq->kickfd);
+ vq->kickfd = ctx;
+ if (vq->ready && vq->kicked && vq->kickfd) {
+ eventfd_signal(vq->kickfd, 1);
+ vq->kicked = false;
+ }
+ spin_unlock(&vq->kick_lock);
+
+ return 0;
+}
+
+static bool vduse_dev_is_ready(struct vduse_dev *dev)
+{
+ int i;
+
+ for (i = 0; i < dev->vq_num; i++)
+ if (!dev->vqs[i].num_max)
+ return false;
+
+ return true;
+}
+
+static void vduse_dev_irq_inject(struct work_struct *work)
+{
+ struct vduse_dev *dev = container_of(work, struct vduse_dev, inject);
+
+ spin_lock_irq(&dev->irq_lock);
+ if (dev->config_cb.callback)
+ dev->config_cb.callback(dev->config_cb.private);
+ spin_unlock_irq(&dev->irq_lock);
+}
+
+static void vduse_vq_irq_inject(struct work_struct *work)
+{
+ struct vduse_virtqueue *vq = container_of(work,
+ struct vduse_virtqueue, inject);
+
+ spin_lock_irq(&vq->irq_lock);
+ if (vq->ready && vq->cb.callback)
+ vq->cb.callback(vq->cb.private);
+ spin_unlock_irq(&vq->irq_lock);
+}
+
+static long vduse_dev_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ struct vduse_dev *dev = file->private_data;
+ void __user *argp = (void __user *)arg;
+ int ret;
+
+ if (unlikely(dev->broken))
+ return -EPERM;
+
+ switch (cmd) {
+ case VDUSE_IOTLB_GET_FD: {
+ struct vduse_iotlb_entry entry;
+ struct vhost_iotlb_map *map;
+ struct vdpa_map_file *map_file;
+ struct vduse_iova_domain *domain = dev->domain;
+ struct file *f = NULL;
+
+ ret = -EFAULT;
+ if (copy_from_user(&entry, argp, sizeof(entry)))
+ break;
+
+ ret = -EINVAL;
+ if (entry.start > entry.last)
+ break;
+
+ spin_lock(&domain->iotlb_lock);
+ map = vhost_iotlb_itree_first(domain->iotlb,
+ entry.start, entry.last);
+ if (map) {
+ map_file = (struct vdpa_map_file *)map->opaque;
+ f = get_file(map_file->file);
+ entry.offset = map_file->offset;
+ entry.start = map->start;
+ entry.last = map->last;
+ entry.perm = map->perm;
+ }
+ spin_unlock(&domain->iotlb_lock);
+ ret = -EINVAL;
+ if (!f)
+ break;
+
+ ret = -EFAULT;
+ if (copy_to_user(argp, &entry, sizeof(entry))) {
+ fput(f);
+ break;
+ }
+ ret = receive_fd(f, perm_to_file_flags(entry.perm));
+ fput(f);
+ break;
+ }
+ case VDUSE_DEV_GET_FEATURES:
+ /*
+ * Just mirror what driver wrote here.
+ * The driver is expected to check FEATURE_OK later.
+ */
+ ret = put_user(dev->driver_features, (u64 __user *)argp);
+ break;
+ case VDUSE_DEV_SET_CONFIG: {
+ struct vduse_config_data config;
+ unsigned long size = offsetof(struct vduse_config_data,
+ buffer);
+
+ ret = -EFAULT;
+ if (copy_from_user(&config, argp, size))
+ break;
+
+ ret = -EINVAL;
+ if (config.length == 0 ||
+ config.length > dev->config_size - config.offset)
+ break;
+
+ ret = -EFAULT;
+ if (copy_from_user(dev->config + config.offset, argp + size,
+ config.length))
+ break;
+
+ ret = 0;
+ break;
+ }
+ case VDUSE_DEV_INJECT_CONFIG_IRQ:
+ ret = 0;
+ queue_work(vduse_irq_wq, &dev->inject);
+ break;
+ case VDUSE_VQ_SETUP: {
+ struct vduse_vq_config config;
+ u32 index;
+
+ ret = -EFAULT;
+ if (copy_from_user(&config, argp, sizeof(config)))
+ break;
+
+ ret = -EINVAL;
+ if (config.index >= dev->vq_num)
+ break;
+
+ index = array_index_nospec(config.index, dev->vq_num);
+ dev->vqs[index].num_max = config.max_size;
+ ret = 0;
+ break;
+ }
+ case VDUSE_VQ_GET_INFO: {
+ struct vduse_vq_info vq_info;
+ struct vduse_virtqueue *vq;
+ u32 index;
+
+ ret = -EFAULT;
+ if (copy_from_user(&vq_info, argp, sizeof(vq_info)))
+ break;
+
+ ret = -EINVAL;
+ if (vq_info.index >= dev->vq_num)
+ break;
+
+ index = array_index_nospec(vq_info.index, dev->vq_num);
+ vq = &dev->vqs[index];
+ vq_info.desc_addr = vq->desc_addr;
+ vq_info.driver_addr = vq->driver_addr;
+ vq_info.device_addr = vq->device_addr;
+ vq_info.num = vq->num;
+
+ if (dev->driver_features & BIT_ULL(VIRTIO_F_RING_PACKED)) {
+ vq_info.packed.last_avail_counter =
+ vq->state.packed.last_avail_counter;
+ vq_info.packed.last_avail_idx =
+ vq->state.packed.last_avail_idx;
+ vq_info.packed.last_used_counter =
+ vq->state.packed.last_used_counter;
+ vq_info.packed.last_used_idx =
+ vq->state.packed.last_used_idx;
+ } else
+ vq_info.split.avail_index =
+ vq->state.split.avail_index;
+
+ vq_info.ready = vq->ready;
+
+ ret = -EFAULT;
+ if (copy_to_user(argp, &vq_info, sizeof(vq_info)))
+ break;
+
+ ret = 0;
+ break;
+ }
+ case VDUSE_VQ_SETUP_KICKFD: {
+ struct vduse_vq_eventfd eventfd;
+
+ ret = -EFAULT;
+ if (copy_from_user(&eventfd, argp, sizeof(eventfd)))
+ break;
+
+ ret = vduse_kickfd_setup(dev, &eventfd);
+ break;
+ }
+ case VDUSE_VQ_INJECT_IRQ: {
+ u32 index;
+
+ ret = -EFAULT;
+ if (get_user(index, (u32 __user *)argp))
+ break;
+
+ ret = -EINVAL;
+ if (index >= dev->vq_num)
+ break;
+
+ ret = 0;
+ index = array_index_nospec(index, dev->vq_num);
+ queue_work(vduse_irq_wq, &dev->vqs[index].inject);
+ break;
+ }
+ default:
+ ret = -ENOIOCTLCMD;
+ break;
+ }
+
+ return ret;
+}
+
+static int vduse_dev_release(struct inode *inode, struct file *file)
+{
+ struct vduse_dev *dev = file->private_data;
+
+ spin_lock(&dev->msg_lock);
+ /* Make sure the inflight messages can processed after reconncection */
+ list_splice_init(&dev->recv_list, &dev->send_list);
+ spin_unlock(&dev->msg_lock);
+ dev->connected = false;
+
+ return 0;
+}
+
+static struct vduse_dev *vduse_dev_get_from_minor(int minor)
+{
+ struct vduse_dev *dev;
+
+ mutex_lock(&vduse_lock);
+ dev = idr_find(&vduse_idr, minor);
+ mutex_unlock(&vduse_lock);
+
+ return dev;
+}
+
+static int vduse_dev_open(struct inode *inode, struct file *file)
+{
+ int ret;
+ struct vduse_dev *dev = vduse_dev_get_from_minor(iminor(inode));
+
+ if (!dev)
+ return -ENODEV;
+
+ ret = -EBUSY;
+ mutex_lock(&dev->lock);
+ if (dev->connected)
+ goto unlock;
+
+ ret = 0;
+ dev->connected = true;
+ file->private_data = dev;
+unlock:
+ mutex_unlock(&dev->lock);
+
+ return ret;
+}
+
+static const struct file_operations vduse_dev_fops = {
+ .owner = THIS_MODULE,
+ .open = vduse_dev_open,
+ .release = vduse_dev_release,
+ .read_iter = vduse_dev_read_iter,
+ .write_iter = vduse_dev_write_iter,
+ .poll = vduse_dev_poll,
+ .unlocked_ioctl = vduse_dev_ioctl,
+ .compat_ioctl = compat_ptr_ioctl,
+ .llseek = noop_llseek,
+};
+
+static struct vduse_dev *vduse_dev_create(void)
+{
+ struct vduse_dev *dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+
+ if (!dev)
+ return NULL;
+
+ mutex_init(&dev->lock);
+ spin_lock_init(&dev->msg_lock);
+ INIT_LIST_HEAD(&dev->send_list);
+ INIT_LIST_HEAD(&dev->recv_list);
+ spin_lock_init(&dev->irq_lock);
+
+ INIT_WORK(&dev->inject, vduse_dev_irq_inject);
+ init_waitqueue_head(&dev->waitq);
+
+ return dev;
+}
+
+static void vduse_dev_destroy(struct vduse_dev *dev)
+{
+ kfree(dev);
+}
+
+static struct vduse_dev *vduse_find_dev(const char *name)
+{
+ struct vduse_dev *dev;
+ int id;
+
+ idr_for_each_entry(&vduse_idr, dev, id)
+ if (!strcmp(dev->name, name))
+ return dev;
+
+ return NULL;
+}
+
+static int vduse_destroy_dev(char *name)
+{
+ struct vduse_dev *dev = vduse_find_dev(name);
+
+ if (!dev)
+ return -EINVAL;
+
+ mutex_lock(&dev->lock);
+ if (dev->vdev || dev->connected) {
+ mutex_unlock(&dev->lock);
+ return -EBUSY;
+ }
+ dev->connected = true;
+ mutex_unlock(&dev->lock);
+
+ vduse_dev_reset(dev);
+ device_destroy(vduse_class, MKDEV(MAJOR(vduse_major), dev->minor));
+ idr_remove(&vduse_idr, dev->minor);
+ kvfree(dev->config);
+ kfree(dev->vqs);
+ vduse_domain_destroy(dev->domain);
+ kfree(dev->name);
+ vduse_dev_destroy(dev);
+ module_put(THIS_MODULE);
+
+ return 0;
+}
+
+static bool device_is_allowed(u32 device_id)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(allowed_device_id); i++)
+ if (allowed_device_id[i] == device_id)
+ return true;
+
+ return false;
+}
+
+static bool features_is_valid(u64 features)
+{
+ if (!(features & (1ULL << VIRTIO_F_ACCESS_PLATFORM)))
+ return false;
+
+ /* Now we only support read-only configuration space */
+ if (features & (1ULL << VIRTIO_BLK_F_CONFIG_WCE))
+ return false;
+
+ return true;
+}
+
+static bool vduse_validate_config(struct vduse_dev_config *config)
+{
+ if (config->vq_align > PAGE_SIZE)
+ return false;
+
+ if (config->config_size > PAGE_SIZE)
+ return false;
+
+ if (!device_is_allowed(config->device_id))
+ return false;
+
+ if (!features_is_valid(config->features))
+ return false;
+
+ return true;
+}
+
+static int vduse_create_dev(struct vduse_dev_config *config,
+ void *config_buf, u64 api_version)
+{
+ int i, ret;
+ struct vduse_dev *dev;
+
+ ret = -EEXIST;
+ if (vduse_find_dev(config->name))
+ goto err;
+
+ ret = -ENOMEM;
+ dev = vduse_dev_create();
+ if (!dev)
+ goto err;
+
+ dev->api_version = api_version;
+ dev->device_features = config->features;
+ dev->device_id = config->device_id;
+ dev->vendor_id = config->vendor_id;
+ dev->name = kstrdup(config->name, GFP_KERNEL);
+ if (!dev->name)
+ goto err_str;
+
+ dev->domain = vduse_domain_create(VDUSE_IOVA_SIZE - 1,
+ VDUSE_BOUNCE_SIZE);
+ if (!dev->domain)
+ goto err_domain;
+
+ dev->config = config_buf;
+ dev->config_size = config->config_size;
+ dev->vq_align = config->vq_align;
+ dev->vq_num = config->vq_num;
+ dev->vqs = kcalloc(dev->vq_num, sizeof(*dev->vqs), GFP_KERNEL);
+ if (!dev->vqs)
+ goto err_vqs;
+
+ for (i = 0; i < dev->vq_num; i++) {
+ dev->vqs[i].index = i;
+ INIT_WORK(&dev->vqs[i].inject, vduse_vq_irq_inject);
+ spin_lock_init(&dev->vqs[i].kick_lock);
+ spin_lock_init(&dev->vqs[i].irq_lock);
+ }
+
+ ret = idr_alloc(&vduse_idr, dev, 1, VDUSE_DEV_MAX, GFP_KERNEL);
+ if (ret < 0)
+ goto err_idr;
+
+ dev->minor = ret;
+ dev->dev = device_create(vduse_class, NULL,
+ MKDEV(MAJOR(vduse_major), dev->minor),
+ NULL, "%s", config->name);
+ if (IS_ERR(dev->dev)) {
+ ret = PTR_ERR(dev->dev);
+ goto err_dev;
+ }
+ __module_get(THIS_MODULE);
+
+ return 0;
+err_dev:
+ idr_remove(&vduse_idr, dev->minor);
+err_idr:
+ kfree(dev->vqs);
+err_vqs:
+ vduse_domain_destroy(dev->domain);
+err_domain:
+ kfree(dev->name);
+err_str:
+ vduse_dev_destroy(dev);
+err:
+ kvfree(config_buf);
+ return ret;
+}
+
+static long vduse_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ int ret;
+ void __user *argp = (void __user *)arg;
+ struct vduse_control *control = file->private_data;
+
+ mutex_lock(&vduse_lock);
+ switch (cmd) {
+ case VDUSE_GET_API_VERSION:
+ ret = put_user(control->api_version, (u64 __user *)argp);
+ break;
+ case VDUSE_SET_API_VERSION: {
+ u64 api_version;
+
+ ret = -EFAULT;
+ if (get_user(api_version, (u64 __user *)argp))
+ break;
+
+ ret = -EINVAL;
+ if (api_version > VDUSE_API_VERSION)
+ break;
+
+ ret = 0;
+ control->api_version = api_version;
+ break;
+ }
+ case VDUSE_CREATE_DEV: {
+ struct vduse_dev_config config;
+ unsigned long size = offsetof(struct vduse_dev_config, config);
+ void *buf;
+
+ ret = -EFAULT;
+ if (copy_from_user(&config, argp, size))
+ break;
+
+ ret = -EINVAL;
+ if (vduse_validate_config(&config) == false)
+ break;
+
+ buf = vmemdup_user(argp + size, config.config_size);
+ if (IS_ERR(buf)) {
+ ret = PTR_ERR(buf);
+ break;
+ }
+ config.name[VDUSE_NAME_MAX - 1] = '\0';
+ ret = vduse_create_dev(&config, buf, control->api_version);
+ break;
+ }
+ case VDUSE_DESTROY_DEV: {
+ char name[VDUSE_NAME_MAX];
+
+ ret = -EFAULT;
+ if (copy_from_user(name, argp, VDUSE_NAME_MAX))
+ break;
+
+ name[VDUSE_NAME_MAX - 1] = '\0';
+ ret = vduse_destroy_dev(name);
+ break;
+ }
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ mutex_unlock(&vduse_lock);
+
+ return ret;
+}
+
+static int vduse_release(struct inode *inode, struct file *file)
+{
+ struct vduse_control *control = file->private_data;
+
+ kfree(control);
+ return 0;
+}
+
+static int vduse_open(struct inode *inode, struct file *file)
+{
+ struct vduse_control *control;
+
+ control = kmalloc(sizeof(struct vduse_control), GFP_KERNEL);
+ if (!control)
+ return -ENOMEM;
+
+ control->api_version = VDUSE_API_VERSION;
+ file->private_data = control;
+
+ return 0;
+}
+
+static const struct file_operations vduse_ctrl_fops = {
+ .owner = THIS_MODULE,
+ .open = vduse_open,
+ .release = vduse_release,
+ .unlocked_ioctl = vduse_ioctl,
+ .compat_ioctl = compat_ptr_ioctl,
+ .llseek = noop_llseek,
+};
+
+static char *vduse_devnode(struct device *dev, umode_t *mode)
+{
+ return kasprintf(GFP_KERNEL, "vduse/%s", dev_name(dev));
+}
+
+static void vduse_mgmtdev_release(struct device *dev)
+{
+}
+
+static struct device vduse_mgmtdev = {
+ .init_name = "vduse",
+ .release = vduse_mgmtdev_release,
+};
+
+static struct vdpa_mgmt_dev mgmt_dev;
+
+static int vduse_dev_init_vdpa(struct vduse_dev *dev, const char *name)
+{
+ struct vduse_vdpa *vdev;
+ int ret;
+
+ if (dev->vdev)
+ return -EEXIST;
+
+ vdev = vdpa_alloc_device(struct vduse_vdpa, vdpa, dev->dev,
+ &vduse_vdpa_config_ops, name, true);
+ if (IS_ERR(vdev))
+ return PTR_ERR(vdev);
+
+ dev->vdev = vdev;
+ vdev->dev = dev;
+ vdev->vdpa.dev.dma_mask = &vdev->vdpa.dev.coherent_dma_mask;
+ ret = dma_set_mask_and_coherent(&vdev->vdpa.dev, DMA_BIT_MASK(64));
+ if (ret) {
+ put_device(&vdev->vdpa.dev);
+ return ret;
+ }
+ set_dma_ops(&vdev->vdpa.dev, &vduse_dev_dma_ops);
+ vdev->vdpa.dma_dev = &vdev->vdpa.dev;
+ vdev->vdpa.mdev = &mgmt_dev;
+
+ return 0;
+}
+
+static int vdpa_dev_add(struct vdpa_mgmt_dev *mdev, const char *name)
+{
+ struct vduse_dev *dev;
+ int ret;
+
+ mutex_lock(&vduse_lock);
+ dev = vduse_find_dev(name);
+ if (!dev || !vduse_dev_is_ready(dev)) {
+ mutex_unlock(&vduse_lock);
+ return -EINVAL;
+ }
+ ret = vduse_dev_init_vdpa(dev, name);
+ mutex_unlock(&vduse_lock);
+ if (ret)
+ return ret;
+
+ ret = _vdpa_register_device(&dev->vdev->vdpa, dev->vq_num);
+ if (ret) {
+ put_device(&dev->vdev->vdpa.dev);
+ return ret;
+ }
+
+ return 0;
+}
+
+static void vdpa_dev_del(struct vdpa_mgmt_dev *mdev, struct vdpa_device *dev)
+{
+ _vdpa_unregister_device(dev);
+}
+
+static const struct vdpa_mgmtdev_ops vdpa_dev_mgmtdev_ops = {
+ .dev_add = vdpa_dev_add,
+ .dev_del = vdpa_dev_del,
+};
+
+static struct virtio_device_id id_table[] = {
+ { VIRTIO_ID_BLOCK, VIRTIO_DEV_ANY_ID },
+ { 0 },
+};
+
+static struct vdpa_mgmt_dev mgmt_dev = {
+ .device = &vduse_mgmtdev,
+ .id_table = id_table,
+ .ops = &vdpa_dev_mgmtdev_ops,
+};
+
+static int vduse_mgmtdev_init(void)
+{
+ int ret;
+
+ ret = device_register(&vduse_mgmtdev);
+ if (ret)
+ return ret;
+
+ ret = vdpa_mgmtdev_register(&mgmt_dev);
+ if (ret)
+ goto err;
+
+ return 0;
+err:
+ device_unregister(&vduse_mgmtdev);
+ return ret;
+}
+
+static void vduse_mgmtdev_exit(void)
+{
+ vdpa_mgmtdev_unregister(&mgmt_dev);
+ device_unregister(&vduse_mgmtdev);
+}
+
+static int vduse_init(void)
+{
+ int ret;
+ struct device *dev;
+
+ vduse_class = class_create(THIS_MODULE, "vduse");
+ if (IS_ERR(vduse_class))
+ return PTR_ERR(vduse_class);
+
+ vduse_class->devnode = vduse_devnode;
+
+ ret = alloc_chrdev_region(&vduse_major, 0, VDUSE_DEV_MAX, "vduse");
+ if (ret)
+ goto err_chardev_region;
+
+ /* /dev/vduse/control */
+ cdev_init(&vduse_ctrl_cdev, &vduse_ctrl_fops);
+ vduse_ctrl_cdev.owner = THIS_MODULE;
+ ret = cdev_add(&vduse_ctrl_cdev, vduse_major, 1);
+ if (ret)
+ goto err_ctrl_cdev;
+
+ dev = device_create(vduse_class, NULL, vduse_major, NULL, "control");
+ if (IS_ERR(dev)) {
+ ret = PTR_ERR(dev);
+ goto err_device;
+ }
+
+ /* /dev/vduse/$DEVICE */
+ cdev_init(&vduse_cdev, &vduse_dev_fops);
+ vduse_cdev.owner = THIS_MODULE;
+ ret = cdev_add(&vduse_cdev, MKDEV(MAJOR(vduse_major), 1),
+ VDUSE_DEV_MAX - 1);
+ if (ret)
+ goto err_cdev;
+
+ vduse_irq_wq = alloc_workqueue("vduse-irq",
+ WQ_HIGHPRI | WQ_SYSFS | WQ_UNBOUND, 0);
+ if (!vduse_irq_wq)
+ goto err_wq;
+
+ ret = vduse_domain_init();
+ if (ret)
+ goto err_domain;
+
+ ret = vduse_mgmtdev_init();
+ if (ret)
+ goto err_mgmtdev;
+
+ return 0;
+err_mgmtdev:
+ vduse_domain_exit();
+err_domain:
+ destroy_workqueue(vduse_irq_wq);
+err_wq:
+ cdev_del(&vduse_cdev);
+err_cdev:
+ device_destroy(vduse_class, vduse_major);
+err_device:
+ cdev_del(&vduse_ctrl_cdev);
+err_ctrl_cdev:
+ unregister_chrdev_region(vduse_major, VDUSE_DEV_MAX);
+err_chardev_region:
+ class_destroy(vduse_class);
+ return ret;
+}
+module_init(vduse_init);
+
+static void vduse_exit(void)
+{
+ vduse_mgmtdev_exit();
+ vduse_domain_exit();
+ destroy_workqueue(vduse_irq_wq);
+ cdev_del(&vduse_cdev);
+ device_destroy(vduse_class, vduse_major);
+ cdev_del(&vduse_ctrl_cdev);
+ unregister_chrdev_region(vduse_major, VDUSE_DEV_MAX);
+ class_destroy(vduse_class);
+}
+module_exit(vduse_exit);
+
+MODULE_LICENSE(DRV_LICENSE);
+MODULE_AUTHOR(DRV_AUTHOR);
+MODULE_DESCRIPTION(DRV_DESC);
diff --git a/include/uapi/linux/vduse.h b/include/uapi/linux/vduse.h
new file mode 100644
index 000000000000..b100a67b112c
--- /dev/null
+++ b/include/uapi/linux/vduse.h
@@ -0,0 +1,220 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _UAPI_VDUSE_H_
+#define _UAPI_VDUSE_H_
+
+#include <linux/types.h>
+
+#define VDUSE_BASE 0x81
+
+/* The ioctls for control device (/dev/vduse/control) */
+
+#define VDUSE_API_VERSION 0
+
+/*
+ * Get the version of VDUSE API that kernel supported (VDUSE_API_VERSION).
+ * This is used for future extension.
+ */
+#define VDUSE_GET_API_VERSION _IOR(VDUSE_BASE, 0x00, __u64)
+
+/* Set the version of VDUSE API that userspace supported. */
+#define VDUSE_SET_API_VERSION _IOW(VDUSE_BASE, 0x01, __u64)
+
+/*
+ * The basic configuration of a VDUSE device, which is used by
+ * VDUSE_CREATE_DEV ioctl to create a VDUSE device.
+ */
+struct vduse_dev_config {
+#define VDUSE_NAME_MAX 256
+ char name[VDUSE_NAME_MAX]; /* vduse device name, needs to be NUL terminated */
+ __u32 vendor_id; /* virtio vendor id */
+ __u32 device_id; /* virtio device id */
+ __u64 features; /* virtio features */
+ __u32 vq_num; /* the number of virtqueues */
+ __u32 vq_align; /* the allocation alignment of virtqueue's metadata */
+ __u32 reserved[13]; /* for future use */
+ __u32 config_size; /* the size of the configuration space */
+ __u8 config[0]; /* the buffer of the configuration space */
+};
+
+/* Create a VDUSE device which is represented by a char device (/dev/vduse/$NAME) */
+#define VDUSE_CREATE_DEV _IOW(VDUSE_BASE, 0x02, struct vduse_dev_config)
+
+/*
+ * Destroy a VDUSE device. Make sure there are no more references
+ * to the char device (/dev/vduse/$NAME).
+ */
+#define VDUSE_DESTROY_DEV _IOW(VDUSE_BASE, 0x03, char[VDUSE_NAME_MAX])
+
+/* The ioctls for VDUSE device (/dev/vduse/$NAME) */
+
+/*
+ * The information of one IOVA region, which is retrieved from
+ * VDUSE_IOTLB_GET_FD ioctl.
+ */
+struct vduse_iotlb_entry {
+ __u64 offset; /* the mmap offset on returned file descriptor */
+ __u64 start; /* start of the IOVA range: [start, last] */
+ __u64 last; /* last of the IOVA range: [start, last] */
+#define VDUSE_ACCESS_RO 0x1
+#define VDUSE_ACCESS_WO 0x2
+#define VDUSE_ACCESS_RW 0x3
+ __u8 perm; /* access permission of this region */
+};
+
+/*
+ * Find the first IOVA region that overlaps with the range [start, last]
+ * and return the corresponding file descriptor. Return -EINVAL means the
+ * IOVA region doesn't exist. Caller should set start and last fields.
+ */
+#define VDUSE_IOTLB_GET_FD _IOWR(VDUSE_BASE, 0x10, struct vduse_iotlb_entry)
+
+/*
+ * Get the negotiated virtio features. It's a subset of the features in
+ * struct vduse_dev_config which can be accepted by virtio driver. It's
+ * only valid after FEATURES_OK status bit is set.
+ */
+#define VDUSE_DEV_GET_FEATURES _IOR(VDUSE_BASE, 0x11, __u64)
+
+/*
+ * The information that is used by VDUSE_DEV_SET_CONFIG ioctl to update
+ * device configuration space.
+ */
+struct vduse_config_data {
+ __u32 offset; /* offset from the beginning of configuration space */
+ __u32 length; /* the length to write to configuration space */
+ __u8 buffer[0]; /* buffer used to write from */
+};
+
+/* Set device configuration space */
+#define VDUSE_DEV_SET_CONFIG _IOW(VDUSE_BASE, 0x12, struct vduse_config_data)
+
+/*
+ * Inject a config interrupt. It's usually used to notify virtio driver
+ * that device configuration space has changed.
+ */
+#define VDUSE_DEV_INJECT_CONFIG_IRQ _IO(VDUSE_BASE, 0x13)
+
+/*
+ * The basic configuration of a virtqueue, which is used by
+ * VDUSE_VQ_SETUP ioctl to setup a virtqueue.
+ */
+struct vduse_vq_config {
+ __u32 index; /* virtqueue index */
+ __u16 max_size; /* the max size of virtqueue */
+};
+
+/*
+ * Setup the specified virtqueue. Make sure all virtqueues have been
+ * configured before the device is attached to vDPA bus.
+ */
+#define VDUSE_VQ_SETUP _IOW(VDUSE_BASE, 0x14, struct vduse_vq_config)
+
+struct vduse_vq_state_split {
+ __u16 avail_index; /* available index */
+};
+
+struct vduse_vq_state_packed {
+ __u16 last_avail_counter:1; /* last driver ring wrap counter observed by device */
+ __u16 last_avail_idx:15; /* device available index */
+ __u16 last_used_counter:1; /* device ring wrap counter */
+ __u16 last_used_idx:15; /* used index */
+};
+
+/*
+ * The information of a virtqueue, which is retrieved from
+ * VDUSE_VQ_GET_INFO ioctl.
+ */
+struct vduse_vq_info {
+ __u32 index; /* virtqueue index */
+ __u32 num; /* the size of virtqueue */
+ __u64 desc_addr; /* address of desc area */
+ __u64 driver_addr; /* address of driver area */
+ __u64 device_addr; /* address of device area */
+ union {
+ struct vduse_vq_state_split split; /* split virtqueue state */
+ struct vduse_vq_state_packed packed; /* packed virtqueue state */
+ };
+ __u8 ready; /* ready status of virtqueue */
+};
+
+/* Get the specified virtqueue's information. Caller should set index field. */
+#define VDUSE_VQ_GET_INFO _IOWR(VDUSE_BASE, 0x15, struct vduse_vq_info)
+
+/*
+ * The eventfd configuration for the specified virtqueue. It's used by
+ * VDUSE_VQ_SETUP_KICKFD ioctl to setup kick eventfd.
+ */
+struct vduse_vq_eventfd {
+ __u32 index; /* virtqueue index */
+#define VDUSE_EVENTFD_DEASSIGN -1
+ int fd; /* eventfd, -1 means de-assigning the eventfd */
+};
+
+/*
+ * Setup kick eventfd for specified virtqueue. The kick eventfd is used
+ * by VDUSE kernel module to notify userspace to consume the avail vring.
+ */
+#define VDUSE_VQ_SETUP_KICKFD _IOW(VDUSE_BASE, 0x16, struct vduse_vq_eventfd)
+
+/*
+ * Inject an interrupt for specific virtqueue. It's used to notify virtio driver
+ * to consume the used vring.
+ */
+#define VDUSE_VQ_INJECT_IRQ _IOW(VDUSE_BASE, 0x17, __u32)
+
+/* The control messages definition for read/write on /dev/vduse/$NAME */
+
+enum vduse_req_type {
+ /* Get the state for specified virtqueue from userspace */
+ VDUSE_GET_VQ_STATE,
+ /* Set the device status */
+ VDUSE_SET_STATUS,
+ /*
+ * Notify userspace to update the memory mapping for specified
+ * IOVA range via VDUSE_IOTLB_GET_FD ioctl
+ */
+ VDUSE_UPDATE_IOTLB,
+};
+
+struct vduse_vq_state {
+ __u32 index; /* virtqueue index */
+ union {
+ struct vduse_vq_state_split split; /* split virtqueue state */
+ struct vduse_vq_state_packed packed; /* packed virtqueue state */
+ };
+};
+
+struct vduse_dev_status {
+ __u8 status; /* device status */
+};
+
+struct vduse_iova_range {
+ __u64 start; /* start of the IOVA range: [start, end] */
+ __u64 last; /* last of the IOVA range: [start, end] */
+};
+
+struct vduse_dev_request {
+ __u32 type; /* request type */
+ __u32 request_id; /* request id */
+ __u32 reserved[2]; /* for future use */
+ union {
+ struct vduse_vq_state vq_state; /* virtqueue state, only use index */
+ struct vduse_dev_status s; /* device status */
+ struct vduse_iova_range iova; /* IOVA range for updating */
+ __u32 padding[16]; /* padding */
+ };
+};
+
+struct vduse_dev_response {
+ __u32 request_id; /* corresponding request id */
+#define VDUSE_REQ_RESULT_OK 0x00
+#define VDUSE_REQ_RESULT_FAILED 0x01
+ __u32 result; /* the result of request */
+ __u32 reserved[2]; /* for future use */
+ union {
+ struct vduse_vq_state vq_state; /* virtqueue state */
+ __u32 padding[16]; /* padding */
+ };
+};
+
+#endif /* _UAPI_VDUSE_H_ */
--
2.11.0
^ permalink raw reply related [flat|nested] 55+ messages in thread* Re: [PATCH v10 16/17] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-07-29 7:35 ` [PATCH v10 16/17] vduse: Introduce VDUSE - vDPA Device in Userspace Xie Yongji
@ 2021-07-29 9:00 ` Greg KH
2021-07-29 9:57 ` Yongji Xie
2021-08-03 7:30 ` Jason Wang
1 sibling, 1 reply; 55+ messages in thread
From: Greg KH @ 2021-07-29 9:00 UTC (permalink / raw)
To: Xie Yongji
Cc: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro, zhe.he, xiaodong.liu, joe, songmuchun,
virtualization, netdev, kvm, linux-fsdevel, iommu, linux-kernel
On Thu, Jul 29, 2021 at 03:35:02PM +0800, Xie Yongji wrote:
> +/*
> + * The basic configuration of a VDUSE device, which is used by
> + * VDUSE_CREATE_DEV ioctl to create a VDUSE device.
> + */
> +struct vduse_dev_config {
Please document this structure using kernel doc so we know what all the
fields are.
> +#define VDUSE_NAME_MAX 256
> + char name[VDUSE_NAME_MAX]; /* vduse device name, needs to be NUL terminated */
> + __u32 vendor_id; /* virtio vendor id */
> + __u32 device_id; /* virtio device id */
> + __u64 features; /* virtio features */
> + __u32 vq_num; /* the number of virtqueues */
> + __u32 vq_align; /* the allocation alignment of virtqueue's metadata */
> + __u32 reserved[13]; /* for future use */
This HAS to be tested to be all 0, otherwise you can never use it in the
future. I did not see the code doing that at all.
> + __u32 config_size; /* the size of the configuration space */
> + __u8 config[0]; /* the buffer of the configuration space */
config[]; please instead? I thought we were getting rid of all of the
0-length arrays in the kernel tree.
> +};
> +
> +/* Create a VDUSE device which is represented by a char device (/dev/vduse/$NAME) */
> +#define VDUSE_CREATE_DEV _IOW(VDUSE_BASE, 0x02, struct vduse_dev_config)
> +
> +/*
> + * Destroy a VDUSE device. Make sure there are no more references
> + * to the char device (/dev/vduse/$NAME).
> + */
> +#define VDUSE_DESTROY_DEV _IOW(VDUSE_BASE, 0x03, char[VDUSE_NAME_MAX])
> +
> +/* The ioctls for VDUSE device (/dev/vduse/$NAME) */
> +
> +/*
> + * The information of one IOVA region, which is retrieved from
> + * VDUSE_IOTLB_GET_FD ioctl.
> + */
> +struct vduse_iotlb_entry {
> + __u64 offset; /* the mmap offset on returned file descriptor */
> + __u64 start; /* start of the IOVA range: [start, last] */
> + __u64 last; /* last of the IOVA range: [start, last] */
> +#define VDUSE_ACCESS_RO 0x1
> +#define VDUSE_ACCESS_WO 0x2
> +#define VDUSE_ACCESS_RW 0x3
> + __u8 perm; /* access permission of this region */
> +};
> +
> +/*
> + * Find the first IOVA region that overlaps with the range [start, last]
> + * and return the corresponding file descriptor. Return -EINVAL means the
> + * IOVA region doesn't exist. Caller should set start and last fields.
> + */
> +#define VDUSE_IOTLB_GET_FD _IOWR(VDUSE_BASE, 0x10, struct vduse_iotlb_entry)
> +
> +/*
> + * Get the negotiated virtio features. It's a subset of the features in
> + * struct vduse_dev_config which can be accepted by virtio driver. It's
> + * only valid after FEATURES_OK status bit is set.
> + */
> +#define VDUSE_DEV_GET_FEATURES _IOR(VDUSE_BASE, 0x11, __u64)
> +
> +/*
> + * The information that is used by VDUSE_DEV_SET_CONFIG ioctl to update
> + * device configuration space.
> + */
> +struct vduse_config_data {
> + __u32 offset; /* offset from the beginning of configuration space */
> + __u32 length; /* the length to write to configuration space */
> + __u8 buffer[0]; /* buffer used to write from */
again, buffer[];?
> +};
> +
> +/* Set device configuration space */
> +#define VDUSE_DEV_SET_CONFIG _IOW(VDUSE_BASE, 0x12, struct vduse_config_data)
> +
> +/*
> + * Inject a config interrupt. It's usually used to notify virtio driver
> + * that device configuration space has changed.
> + */
> +#define VDUSE_DEV_INJECT_CONFIG_IRQ _IO(VDUSE_BASE, 0x13)
> +
> +/*
> + * The basic configuration of a virtqueue, which is used by
> + * VDUSE_VQ_SETUP ioctl to setup a virtqueue.
> + */
> +struct vduse_vq_config {
> + __u32 index; /* virtqueue index */
> + __u16 max_size; /* the max size of virtqueue */
> +};
> +
> +/*
> + * Setup the specified virtqueue. Make sure all virtqueues have been
> + * configured before the device is attached to vDPA bus.
> + */
> +#define VDUSE_VQ_SETUP _IOW(VDUSE_BASE, 0x14, struct vduse_vq_config)
> +
> +struct vduse_vq_state_split {
> + __u16 avail_index; /* available index */
> +};
> +
> +struct vduse_vq_state_packed {
> + __u16 last_avail_counter:1; /* last driver ring wrap counter observed by device */
> + __u16 last_avail_idx:15; /* device available index */
Bit fields in a user structure? Are you sure this is going to work
well? Why not just make this a __u16 and then mask off what you want so
that you do not run into endian issues?
> + __u16 last_used_counter:1; /* device ring wrap counter */
> + __u16 last_used_idx:15; /* used index */
> +};
> +
> +/*
> + * The information of a virtqueue, which is retrieved from
> + * VDUSE_VQ_GET_INFO ioctl.
> + */
> +struct vduse_vq_info {
> + __u32 index; /* virtqueue index */
> + __u32 num; /* the size of virtqueue */
> + __u64 desc_addr; /* address of desc area */
> + __u64 driver_addr; /* address of driver area */
> + __u64 device_addr; /* address of device area */
> + union {
> + struct vduse_vq_state_split split; /* split virtqueue state */
> + struct vduse_vq_state_packed packed; /* packed virtqueue state */
> + };
> + __u8 ready; /* ready status of virtqueue */
> +};
> +
> +/* Get the specified virtqueue's information. Caller should set index field. */
> +#define VDUSE_VQ_GET_INFO _IOWR(VDUSE_BASE, 0x15, struct vduse_vq_info)
> +
> +/*
> + * The eventfd configuration for the specified virtqueue. It's used by
> + * VDUSE_VQ_SETUP_KICKFD ioctl to setup kick eventfd.
> + */
> +struct vduse_vq_eventfd {
> + __u32 index; /* virtqueue index */
> +#define VDUSE_EVENTFD_DEASSIGN -1
> + int fd; /* eventfd, -1 means de-assigning the eventfd */
Don't we have a file descriptor type? I could be wrong.
> +};
> +
> +/*
> + * Setup kick eventfd for specified virtqueue. The kick eventfd is used
> + * by VDUSE kernel module to notify userspace to consume the avail vring.
> + */
> +#define VDUSE_VQ_SETUP_KICKFD _IOW(VDUSE_BASE, 0x16, struct vduse_vq_eventfd)
> +
> +/*
> + * Inject an interrupt for specific virtqueue. It's used to notify virtio driver
> + * to consume the used vring.
> + */
> +#define VDUSE_VQ_INJECT_IRQ _IOW(VDUSE_BASE, 0x17, __u32)
> +
> +/* The control messages definition for read/write on /dev/vduse/$NAME */
> +
> +enum vduse_req_type {
> + /* Get the state for specified virtqueue from userspace */
> + VDUSE_GET_VQ_STATE,
> + /* Set the device status */
> + VDUSE_SET_STATUS,
> + /*
> + * Notify userspace to update the memory mapping for specified
> + * IOVA range via VDUSE_IOTLB_GET_FD ioctl
> + */
> + VDUSE_UPDATE_IOTLB,
> +};
> +
> +struct vduse_vq_state {
> + __u32 index; /* virtqueue index */
> + union {
> + struct vduse_vq_state_split split; /* split virtqueue state */
> + struct vduse_vq_state_packed packed; /* packed virtqueue state */
> + };
> +};
> +
> +struct vduse_dev_status {
> + __u8 status; /* device status */
> +};
> +
> +struct vduse_iova_range {
> + __u64 start; /* start of the IOVA range: [start, end] */
> + __u64 last; /* last of the IOVA range: [start, end] */
> +};
> +
> +struct vduse_dev_request {
> + __u32 type; /* request type */
> + __u32 request_id; /* request id */
> + __u32 reserved[2]; /* for future use */
Again, this HAS to be checked to be 0 and aborted if not, otherwise you
can never use it in the future.
> + union {
> + struct vduse_vq_state vq_state; /* virtqueue state, only use index */
> + struct vduse_dev_status s; /* device status */
> + struct vduse_iova_range iova; /* IOVA range for updating */
> + __u32 padding[16]; /* padding */
> + };
> +};
> +
> +struct vduse_dev_response {
> + __u32 request_id; /* corresponding request id */
> +#define VDUSE_REQ_RESULT_OK 0x00
> +#define VDUSE_REQ_RESULT_FAILED 0x01
> + __u32 result; /* the result of request */
> + __u32 reserved[2]; /* for future use */
Same here, you have to check this.
> + union {
> + struct vduse_vq_state vq_state; /* virtqueue state */
> + __u32 padding[16]; /* padding */
Check this padding too.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 55+ messages in thread* Re: [PATCH v10 16/17] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-07-29 9:00 ` Greg KH
@ 2021-07-29 9:57 ` Yongji Xie
0 siblings, 0 replies; 55+ messages in thread
From: Yongji Xie @ 2021-07-29 9:57 UTC (permalink / raw)
To: Greg KH
Cc: Michael S. Tsirkin, Jason Wang, Stefan Hajnoczi,
Stefano Garzarella, Parav Pandit, Christoph Hellwig,
Christian Brauner, Randy Dunlap, Matthew Wilcox, Al Viro,
Jens Axboe, bcrl, Jonathan Corbet, Mika Penttilä,
Dan Carpenter, joro, He Zhe, Liu Xiaodong, Joe Perches,
songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
On Thu, Jul 29, 2021 at 5:00 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Thu, Jul 29, 2021 at 03:35:02PM +0800, Xie Yongji wrote:
> > +/*
> > + * The basic configuration of a VDUSE device, which is used by
> > + * VDUSE_CREATE_DEV ioctl to create a VDUSE device.
> > + */
> > +struct vduse_dev_config {
>
> Please document this structure using kernel doc so we know what all the
> fields are.
>
Sure.
> > +#define VDUSE_NAME_MAX 256
> > + char name[VDUSE_NAME_MAX]; /* vduse device name, needs to be NUL terminated */
> > + __u32 vendor_id; /* virtio vendor id */
> > + __u32 device_id; /* virtio device id */
> > + __u64 features; /* virtio features */
> > + __u32 vq_num; /* the number of virtqueues */
> > + __u32 vq_align; /* the allocation alignment of virtqueue's metadata */
> > + __u32 reserved[13]; /* for future use */
>
> This HAS to be tested to be all 0, otherwise you can never use it in the
> future. I did not see the code doing that at all.
>
Make sense. Will do it in the next version.
> > + __u32 config_size; /* the size of the configuration space */
> > + __u8 config[0]; /* the buffer of the configuration space */
>
> config[]; please instead? I thought we were getting rid of all of the
> 0-length arrays in the kernel tree.
>
OK.
> > +};
> > +
> > +/* Create a VDUSE device which is represented by a char device (/dev/vduse/$NAME) */
> > +#define VDUSE_CREATE_DEV _IOW(VDUSE_BASE, 0x02, struct vduse_dev_config)
> > +
> > +/*
> > + * Destroy a VDUSE device. Make sure there are no more references
> > + * to the char device (/dev/vduse/$NAME).
> > + */
> > +#define VDUSE_DESTROY_DEV _IOW(VDUSE_BASE, 0x03, char[VDUSE_NAME_MAX])
> > +
> > +/* The ioctls for VDUSE device (/dev/vduse/$NAME) */
> > +
> > +/*
> > + * The information of one IOVA region, which is retrieved from
> > + * VDUSE_IOTLB_GET_FD ioctl.
> > + */
> > +struct vduse_iotlb_entry {
> > + __u64 offset; /* the mmap offset on returned file descriptor */
> > + __u64 start; /* start of the IOVA range: [start, last] */
> > + __u64 last; /* last of the IOVA range: [start, last] */
> > +#define VDUSE_ACCESS_RO 0x1
> > +#define VDUSE_ACCESS_WO 0x2
> > +#define VDUSE_ACCESS_RW 0x3
> > + __u8 perm; /* access permission of this region */
> > +};
> > +
> > +/*
> > + * Find the first IOVA region that overlaps with the range [start, last]
> > + * and return the corresponding file descriptor. Return -EINVAL means the
> > + * IOVA region doesn't exist. Caller should set start and last fields.
> > + */
> > +#define VDUSE_IOTLB_GET_FD _IOWR(VDUSE_BASE, 0x10, struct vduse_iotlb_entry)
> > +
> > +/*
> > + * Get the negotiated virtio features. It's a subset of the features in
> > + * struct vduse_dev_config which can be accepted by virtio driver. It's
> > + * only valid after FEATURES_OK status bit is set.
> > + */
> > +#define VDUSE_DEV_GET_FEATURES _IOR(VDUSE_BASE, 0x11, __u64)
> > +
> > +/*
> > + * The information that is used by VDUSE_DEV_SET_CONFIG ioctl to update
> > + * device configuration space.
> > + */
> > +struct vduse_config_data {
> > + __u32 offset; /* offset from the beginning of configuration space */
> > + __u32 length; /* the length to write to configuration space */
> > + __u8 buffer[0]; /* buffer used to write from */
>
> again, buffer[];?
>
OK.
> > +};
> > +
> > +/* Set device configuration space */
> > +#define VDUSE_DEV_SET_CONFIG _IOW(VDUSE_BASE, 0x12, struct vduse_config_data)
> > +
> > +/*
> > + * Inject a config interrupt. It's usually used to notify virtio driver
> > + * that device configuration space has changed.
> > + */
> > +#define VDUSE_DEV_INJECT_CONFIG_IRQ _IO(VDUSE_BASE, 0x13)
> > +
> > +/*
> > + * The basic configuration of a virtqueue, which is used by
> > + * VDUSE_VQ_SETUP ioctl to setup a virtqueue.
> > + */
> > +struct vduse_vq_config {
> > + __u32 index; /* virtqueue index */
> > + __u16 max_size; /* the max size of virtqueue */
> > +};
> > +
> > +/*
> > + * Setup the specified virtqueue. Make sure all virtqueues have been
> > + * configured before the device is attached to vDPA bus.
> > + */
> > +#define VDUSE_VQ_SETUP _IOW(VDUSE_BASE, 0x14, struct vduse_vq_config)
> > +
> > +struct vduse_vq_state_split {
> > + __u16 avail_index; /* available index */
> > +};
> > +
> > +struct vduse_vq_state_packed {
> > + __u16 last_avail_counter:1; /* last driver ring wrap counter observed by device */
> > + __u16 last_avail_idx:15; /* device available index */
>
> Bit fields in a user structure? Are you sure this is going to work
> well? Why not just make this a __u16 and then mask off what you want so
> that you do not run into endian issues?
>
Good point! I will use __u16 for each field instead.
> > + __u16 last_used_counter:1; /* device ring wrap counter */
> > + __u16 last_used_idx:15; /* used index */
> > +};
> > +
> > +/*
> > + * The information of a virtqueue, which is retrieved from
> > + * VDUSE_VQ_GET_INFO ioctl.
> > + */
> > +struct vduse_vq_info {
> > + __u32 index; /* virtqueue index */
> > + __u32 num; /* the size of virtqueue */
> > + __u64 desc_addr; /* address of desc area */
> > + __u64 driver_addr; /* address of driver area */
> > + __u64 device_addr; /* address of device area */
> > + union {
> > + struct vduse_vq_state_split split; /* split virtqueue state */
> > + struct vduse_vq_state_packed packed; /* packed virtqueue state */
> > + };
> > + __u8 ready; /* ready status of virtqueue */
> > +};
> > +
> > +/* Get the specified virtqueue's information. Caller should set index field. */
> > +#define VDUSE_VQ_GET_INFO _IOWR(VDUSE_BASE, 0x15, struct vduse_vq_info)
> > +
> > +/*
> > + * The eventfd configuration for the specified virtqueue. It's used by
> > + * VDUSE_VQ_SETUP_KICKFD ioctl to setup kick eventfd.
> > + */
> > +struct vduse_vq_eventfd {
> > + __u32 index; /* virtqueue index */
> > +#define VDUSE_EVENTFD_DEASSIGN -1
> > + int fd; /* eventfd, -1 means de-assigning the eventfd */
>
> Don't we have a file descriptor type? I could be wrong.
>
It looks like I did not find it...
> > +};
> > +
> > +/*
> > + * Setup kick eventfd for specified virtqueue. The kick eventfd is used
> > + * by VDUSE kernel module to notify userspace to consume the avail vring.
> > + */
> > +#define VDUSE_VQ_SETUP_KICKFD _IOW(VDUSE_BASE, 0x16, struct vduse_vq_eventfd)
> > +
> > +/*
> > + * Inject an interrupt for specific virtqueue. It's used to notify virtio driver
> > + * to consume the used vring.
> > + */
> > +#define VDUSE_VQ_INJECT_IRQ _IOW(VDUSE_BASE, 0x17, __u32)
> > +
> > +/* The control messages definition for read/write on /dev/vduse/$NAME */
> > +
> > +enum vduse_req_type {
> > + /* Get the state for specified virtqueue from userspace */
> > + VDUSE_GET_VQ_STATE,
> > + /* Set the device status */
> > + VDUSE_SET_STATUS,
> > + /*
> > + * Notify userspace to update the memory mapping for specified
> > + * IOVA range via VDUSE_IOTLB_GET_FD ioctl
> > + */
> > + VDUSE_UPDATE_IOTLB,
> > +};
> > +
> > +struct vduse_vq_state {
> > + __u32 index; /* virtqueue index */
> > + union {
> > + struct vduse_vq_state_split split; /* split virtqueue state */
> > + struct vduse_vq_state_packed packed; /* packed virtqueue state */
> > + };
> > +};
> > +
> > +struct vduse_dev_status {
> > + __u8 status; /* device status */
> > +};
> > +
> > +struct vduse_iova_range {
> > + __u64 start; /* start of the IOVA range: [start, end] */
> > + __u64 last; /* last of the IOVA range: [start, end] */
> > +};
> > +
> > +struct vduse_dev_request {
> > + __u32 type; /* request type */
> > + __u32 request_id; /* request id */
> > + __u32 reserved[2]; /* for future use */
>
> Again, this HAS to be checked to be 0 and aborted if not, otherwise you
> can never use it in the future.
>
I see. This has already been done in the current version.
> > + union {
> > + struct vduse_vq_state vq_state; /* virtqueue state, only use index */
> > + struct vduse_dev_status s; /* device status */
> > + struct vduse_iova_range iova; /* IOVA range for updating */
> > + __u32 padding[16]; /* padding */
> > + };
> > +};
> > +
> > +struct vduse_dev_response {
> > + __u32 request_id; /* corresponding request id */
> > +#define VDUSE_REQ_RESULT_OK 0x00
> > +#define VDUSE_REQ_RESULT_FAILED 0x01
> > + __u32 result; /* the result of request */
> > + __u32 reserved[2]; /* for future use */
>
> Same here, you have to check this.
>
Sure.
> > + union {
> > + struct vduse_vq_state vq_state; /* virtqueue state */
> > + __u32 padding[16]; /* padding */
>
> Check this padding too.
>
OK.
Thanks,
Yongji
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH v10 16/17] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-07-29 7:35 ` [PATCH v10 16/17] vduse: Introduce VDUSE - vDPA Device in Userspace Xie Yongji
2021-07-29 9:00 ` Greg KH
@ 2021-08-03 7:30 ` Jason Wang
2021-08-03 8:39 ` Yongji Xie
1 sibling, 1 reply; 55+ messages in thread
From: Jason Wang @ 2021-08-03 7:30 UTC (permalink / raw)
To: Xie Yongji, mst, stefanha, sgarzare, parav, hch,
christian.brauner, rdunlap, willy, viro, axboe, bcrl, corbet,
mika.penttila, dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu,
joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
在 2021/7/29 下午3:35, Xie Yongji 写道:
> This VDUSE driver enables implementing software-emulated vDPA
> devices in userspace. The vDPA device is created by
> ioctl(VDUSE_CREATE_DEV) on /dev/vduse/control. Then a char device
> interface (/dev/vduse/$NAME) is exported to userspace for device
> emulation.
>
> In order to make the device emulation more secure, the device's
> control path is handled in kernel. A message mechnism is introduced
> to forward some dataplane related control messages to userspace.
>
> And in the data path, the DMA buffer will be mapped into userspace
> address space through different ways depending on the vDPA bus to
> which the vDPA device is attached. In virtio-vdpa case, the MMU-based
> software IOTLB is used to achieve that. And in vhost-vdpa case, the
> DMA buffer is reside in a userspace memory region which can be shared
> to the VDUSE userspace processs via transferring the shmfd.
>
> For more details on VDUSE design and usage, please see the follow-on
> Documentation commit.
>
> Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> ---
> Documentation/userspace-api/ioctl/ioctl-number.rst | 1 +
> drivers/vdpa/Kconfig | 10 +
> drivers/vdpa/Makefile | 1 +
> drivers/vdpa/vdpa_user/Makefile | 5 +
> drivers/vdpa/vdpa_user/vduse_dev.c | 1541 ++++++++++++++++++++
> include/uapi/linux/vduse.h | 220 +++
> 6 files changed, 1778 insertions(+)
> create mode 100644 drivers/vdpa/vdpa_user/Makefile
> create mode 100644 drivers/vdpa/vdpa_user/vduse_dev.c
> create mode 100644 include/uapi/linux/vduse.h
>
> diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst
> index 1409e40e6345..293ca3aef358 100644
> --- a/Documentation/userspace-api/ioctl/ioctl-number.rst
> +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
> @@ -300,6 +300,7 @@ Code Seq# Include File Comments
> 'z' 10-4F drivers/s390/crypto/zcrypt_api.h conflict!
> '|' 00-7F linux/media.h
> 0x80 00-1F linux/fb.h
> +0x81 00-1F linux/vduse.h
> 0x89 00-06 arch/x86/include/asm/sockios.h
> 0x89 0B-DF linux/sockios.h
> 0x89 E0-EF linux/sockios.h SIOCPROTOPRIVATE range
> diff --git a/drivers/vdpa/Kconfig b/drivers/vdpa/Kconfig
> index a503c1b2bfd9..6e23bce6433a 100644
> --- a/drivers/vdpa/Kconfig
> +++ b/drivers/vdpa/Kconfig
> @@ -33,6 +33,16 @@ config VDPA_SIM_BLOCK
> vDPA block device simulator which terminates IO request in a
> memory buffer.
>
> +config VDPA_USER
> + tristate "VDUSE (vDPA Device in Userspace) support"
> + depends on EVENTFD && MMU && HAS_DMA
> + select DMA_OPS
> + select VHOST_IOTLB
> + select IOMMU_IOVA
> + help
> + With VDUSE it is possible to emulate a vDPA Device
> + in a userspace program.
> +
> config IFCVF
> tristate "Intel IFC VF vDPA driver"
> depends on PCI_MSI
> diff --git a/drivers/vdpa/Makefile b/drivers/vdpa/Makefile
> index 67fe7f3d6943..f02ebed33f19 100644
> --- a/drivers/vdpa/Makefile
> +++ b/drivers/vdpa/Makefile
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
> obj-$(CONFIG_VDPA) += vdpa.o
> obj-$(CONFIG_VDPA_SIM) += vdpa_sim/
> +obj-$(CONFIG_VDPA_USER) += vdpa_user/
> obj-$(CONFIG_IFCVF) += ifcvf/
> obj-$(CONFIG_MLX5_VDPA) += mlx5/
> obj-$(CONFIG_VP_VDPA) += virtio_pci/
> diff --git a/drivers/vdpa/vdpa_user/Makefile b/drivers/vdpa/vdpa_user/Makefile
> new file mode 100644
> index 000000000000..260e0b26af99
> --- /dev/null
> +++ b/drivers/vdpa/vdpa_user/Makefile
> @@ -0,0 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +vduse-y := vduse_dev.o iova_domain.o
> +
> +obj-$(CONFIG_VDPA_USER) += vduse.o
> diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
> new file mode 100644
> index 000000000000..6addc62e7de6
> --- /dev/null
> +++ b/drivers/vdpa/vdpa_user/vduse_dev.c
> @@ -0,0 +1,1541 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * VDUSE: vDPA Device in Userspace
> + *
> + * Copyright (C) 2020-2021 Bytedance Inc. and/or its affiliates. All rights reserved.
> + *
> + * Author: Xie Yongji <xieyongji@bytedance.com>
> + *
> + */
> +
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/cdev.h>
> +#include <linux/device.h>
> +#include <linux/eventfd.h>
> +#include <linux/slab.h>
> +#include <linux/wait.h>
> +#include <linux/dma-map-ops.h>
> +#include <linux/poll.h>
> +#include <linux/file.h>
> +#include <linux/uio.h>
> +#include <linux/vdpa.h>
> +#include <linux/nospec.h>
> +#include <uapi/linux/vduse.h>
> +#include <uapi/linux/vdpa.h>
> +#include <uapi/linux/virtio_config.h>
> +#include <uapi/linux/virtio_ids.h>
> +#include <uapi/linux/virtio_blk.h>
> +#include <linux/mod_devicetable.h>
> +
> +#include "iova_domain.h"
> +
> +#define DRV_AUTHOR "Yongji Xie <xieyongji@bytedance.com>"
> +#define DRV_DESC "vDPA Device in Userspace"
> +#define DRV_LICENSE "GPL v2"
> +
> +#define VDUSE_DEV_MAX (1U << MINORBITS)
> +#define VDUSE_BOUNCE_SIZE (64 * 1024 * 1024)
> +#define VDUSE_IOVA_SIZE (128 * 1024 * 1024)
> +#define VDUSE_REQUEST_TIMEOUT 30
I think we need make this as a module parameter. 0 probably means we
need to wait for ever.
This can help in the case when the userspace is attached by GDB. If
Michael is still not happy, we can find other solution (e.g only offload
the datapath).
Other looks good.
Thanks
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH v10 16/17] vduse: Introduce VDUSE - vDPA Device in Userspace
2021-08-03 7:30 ` Jason Wang
@ 2021-08-03 8:39 ` Yongji Xie
0 siblings, 0 replies; 55+ messages in thread
From: Yongji Xie @ 2021-08-03 8:39 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, Greg KH, He Zhe, Liu Xiaodong, Joe Perches,
songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
On Tue, Aug 3, 2021 at 3:30 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/7/29 下午3:35, Xie Yongji 写道:
> > This VDUSE driver enables implementing software-emulated vDPA
> > devices in userspace. The vDPA device is created by
> > ioctl(VDUSE_CREATE_DEV) on /dev/vduse/control. Then a char device
> > interface (/dev/vduse/$NAME) is exported to userspace for device
> > emulation.
> >
> > In order to make the device emulation more secure, the device's
> > control path is handled in kernel. A message mechnism is introduced
> > to forward some dataplane related control messages to userspace.
> >
> > And in the data path, the DMA buffer will be mapped into userspace
> > address space through different ways depending on the vDPA bus to
> > which the vDPA device is attached. In virtio-vdpa case, the MMU-based
> > software IOTLB is used to achieve that. And in vhost-vdpa case, the
> > DMA buffer is reside in a userspace memory region which can be shared
> > to the VDUSE userspace processs via transferring the shmfd.
> >
> > For more details on VDUSE design and usage, please see the follow-on
> > Documentation commit.
> >
> > Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> > ---
> > Documentation/userspace-api/ioctl/ioctl-number.rst | 1 +
> > drivers/vdpa/Kconfig | 10 +
> > drivers/vdpa/Makefile | 1 +
> > drivers/vdpa/vdpa_user/Makefile | 5 +
> > drivers/vdpa/vdpa_user/vduse_dev.c | 1541 ++++++++++++++++++++
> > include/uapi/linux/vduse.h | 220 +++
> > 6 files changed, 1778 insertions(+)
> > create mode 100644 drivers/vdpa/vdpa_user/Makefile
> > create mode 100644 drivers/vdpa/vdpa_user/vduse_dev.c
> > create mode 100644 include/uapi/linux/vduse.h
> >
> > diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst
> > index 1409e40e6345..293ca3aef358 100644
> > --- a/Documentation/userspace-api/ioctl/ioctl-number.rst
> > +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
> > @@ -300,6 +300,7 @@ Code Seq# Include File Comments
> > 'z' 10-4F drivers/s390/crypto/zcrypt_api.h conflict!
> > '|' 00-7F linux/media.h
> > 0x80 00-1F linux/fb.h
> > +0x81 00-1F linux/vduse.h
> > 0x89 00-06 arch/x86/include/asm/sockios.h
> > 0x89 0B-DF linux/sockios.h
> > 0x89 E0-EF linux/sockios.h SIOCPROTOPRIVATE range
> > diff --git a/drivers/vdpa/Kconfig b/drivers/vdpa/Kconfig
> > index a503c1b2bfd9..6e23bce6433a 100644
> > --- a/drivers/vdpa/Kconfig
> > +++ b/drivers/vdpa/Kconfig
> > @@ -33,6 +33,16 @@ config VDPA_SIM_BLOCK
> > vDPA block device simulator which terminates IO request in a
> > memory buffer.
> >
> > +config VDPA_USER
> > + tristate "VDUSE (vDPA Device in Userspace) support"
> > + depends on EVENTFD && MMU && HAS_DMA
> > + select DMA_OPS
> > + select VHOST_IOTLB
> > + select IOMMU_IOVA
> > + help
> > + With VDUSE it is possible to emulate a vDPA Device
> > + in a userspace program.
> > +
> > config IFCVF
> > tristate "Intel IFC VF vDPA driver"
> > depends on PCI_MSI
> > diff --git a/drivers/vdpa/Makefile b/drivers/vdpa/Makefile
> > index 67fe7f3d6943..f02ebed33f19 100644
> > --- a/drivers/vdpa/Makefile
> > +++ b/drivers/vdpa/Makefile
> > @@ -1,6 +1,7 @@
> > # SPDX-License-Identifier: GPL-2.0
> > obj-$(CONFIG_VDPA) += vdpa.o
> > obj-$(CONFIG_VDPA_SIM) += vdpa_sim/
> > +obj-$(CONFIG_VDPA_USER) += vdpa_user/
> > obj-$(CONFIG_IFCVF) += ifcvf/
> > obj-$(CONFIG_MLX5_VDPA) += mlx5/
> > obj-$(CONFIG_VP_VDPA) += virtio_pci/
> > diff --git a/drivers/vdpa/vdpa_user/Makefile b/drivers/vdpa/vdpa_user/Makefile
> > new file mode 100644
> > index 000000000000..260e0b26af99
> > --- /dev/null
> > +++ b/drivers/vdpa/vdpa_user/Makefile
> > @@ -0,0 +1,5 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +
> > +vduse-y := vduse_dev.o iova_domain.o
> > +
> > +obj-$(CONFIG_VDPA_USER) += vduse.o
> > diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
> > new file mode 100644
> > index 000000000000..6addc62e7de6
> > --- /dev/null
> > +++ b/drivers/vdpa/vdpa_user/vduse_dev.c
> > @@ -0,0 +1,1541 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * VDUSE: vDPA Device in Userspace
> > + *
> > + * Copyright (C) 2020-2021 Bytedance Inc. and/or its affiliates. All rights reserved.
> > + *
> > + * Author: Xie Yongji <xieyongji@bytedance.com>
> > + *
> > + */
> > +
> > +#include <linux/init.h>
> > +#include <linux/module.h>
> > +#include <linux/cdev.h>
> > +#include <linux/device.h>
> > +#include <linux/eventfd.h>
> > +#include <linux/slab.h>
> > +#include <linux/wait.h>
> > +#include <linux/dma-map-ops.h>
> > +#include <linux/poll.h>
> > +#include <linux/file.h>
> > +#include <linux/uio.h>
> > +#include <linux/vdpa.h>
> > +#include <linux/nospec.h>
> > +#include <uapi/linux/vduse.h>
> > +#include <uapi/linux/vdpa.h>
> > +#include <uapi/linux/virtio_config.h>
> > +#include <uapi/linux/virtio_ids.h>
> > +#include <uapi/linux/virtio_blk.h>
> > +#include <linux/mod_devicetable.h>
> > +
> > +#include "iova_domain.h"
> > +
> > +#define DRV_AUTHOR "Yongji Xie <xieyongji@bytedance.com>"
> > +#define DRV_DESC "vDPA Device in Userspace"
> > +#define DRV_LICENSE "GPL v2"
> > +
> > +#define VDUSE_DEV_MAX (1U << MINORBITS)
> > +#define VDUSE_BOUNCE_SIZE (64 * 1024 * 1024)
> > +#define VDUSE_IOVA_SIZE (128 * 1024 * 1024)
> > +#define VDUSE_REQUEST_TIMEOUT 30
>
>
> I think we need make this as a module parameter. 0 probably means we
> need to wait for ever.
>
> This can help in the case when the userspace is attached by GDB. If
> Michael is still not happy, we can find other solution (e.g only offload
> the datapath).
>
OK, a device attribute might be better.
Thanks,
Yongji
^ permalink raw reply [flat|nested] 55+ messages in thread
* [PATCH v10 17/17] Documentation: Add documentation for VDUSE
2021-07-29 7:34 [PATCH v10 00/17] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
` (15 preceding siblings ...)
2021-07-29 7:35 ` [PATCH v10 16/17] vduse: Introduce VDUSE - vDPA Device in Userspace Xie Yongji
@ 2021-07-29 7:35 ` Xie Yongji
2021-08-03 7:35 ` Jason Wang
16 siblings, 1 reply; 55+ messages in thread
From: Xie Yongji @ 2021-07-29 7:35 UTC (permalink / raw)
To: mst, jasowang, stefanha, sgarzare, parav, hch, christian.brauner,
rdunlap, willy, viro, axboe, bcrl, corbet, mika.penttila,
dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu, joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
VDUSE (vDPA Device in Userspace) is a framework to support
implementing software-emulated vDPA devices in userspace. This
document is intended to clarify the VDUSE design and usage.
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
---
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/vduse.rst | 232 ++++++++++++++++++++++++++++++++++
2 files changed, 233 insertions(+)
create mode 100644 Documentation/userspace-api/vduse.rst
diff --git a/Documentation/userspace-api/index.rst b/Documentation/userspace-api/index.rst
index 0b5eefed027e..c432be070f67 100644
--- a/Documentation/userspace-api/index.rst
+++ b/Documentation/userspace-api/index.rst
@@ -27,6 +27,7 @@ place where this information is gathered.
iommu
media/index
sysfs-platform_profile
+ vduse
.. only:: subproject and html
diff --git a/Documentation/userspace-api/vduse.rst b/Documentation/userspace-api/vduse.rst
new file mode 100644
index 000000000000..30c9d1482126
--- /dev/null
+++ b/Documentation/userspace-api/vduse.rst
@@ -0,0 +1,232 @@
+==================================
+VDUSE - "vDPA Device in Userspace"
+==================================
+
+vDPA (virtio data path acceleration) 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. VDUSE is a framework that makes it
+possible to implement software-emulated vDPA devices in userspace. And
+to make the device emulation more secure, the emulated vDPA device's
+control path is handled in the kernel and only the data path is
+implemented in the userspace.
+
+Note that only virtio block device is supported by VDUSE framework now,
+which can reduce security risks when the userspace process that implements
+the data path is run by an unprivileged user. The support for other device
+types can be added after the security issue of corresponding device driver
+is clarified or fixed in the future.
+
+Create/Destroy VDUSE devices
+------------------------
+
+VDUSE devices are created as follows:
+
+1. Create a new VDUSE instance with ioctl(VDUSE_CREATE_DEV) on
+ /dev/vduse/control.
+
+2. Setup each virtqueue with ioctl(VDUSE_VQ_SETUP) on /dev/vduse/$NAME.
+
+3. Begin processing VDUSE messages from /dev/vduse/$NAME. The first
+ messages will arrive while attaching the VDUSE instance to vDPA bus.
+
+4. Send the VDPA_CMD_DEV_NEW netlink message to attach the VDUSE
+ instance to vDPA bus.
+
+VDUSE devices are destroyed as follows:
+
+1. Send the VDPA_CMD_DEV_DEL netlink message to detach the VDUSE
+ instance from vDPA bus.
+
+2. Close the file descriptor referring to /dev/vduse/$NAME.
+
+3. Destroy the VDUSE instance with ioctl(VDUSE_DESTROY_DEV) on
+ /dev/vduse/control.
+
+The netlink messages can be sent via vdpa tool in iproute2 or use the
+below sample codes:
+
+.. code-block:: c
+
+ static int netlink_add_vduse(const char *name, enum vdpa_command cmd)
+ {
+ struct nl_sock *nlsock;
+ struct nl_msg *msg;
+ int famid;
+
+ nlsock = nl_socket_alloc();
+ if (!nlsock)
+ return -ENOMEM;
+
+ if (genl_connect(nlsock))
+ goto free_sock;
+
+ famid = genl_ctrl_resolve(nlsock, VDPA_GENL_NAME);
+ if (famid < 0)
+ goto close_sock;
+
+ msg = nlmsg_alloc();
+ if (!msg)
+ goto close_sock;
+
+ if (!genlmsg_put(msg, NL_AUTO_PORT, NL_AUTO_SEQ, famid, 0, 0, cmd, 0))
+ goto nla_put_failure;
+
+ NLA_PUT_STRING(msg, VDPA_ATTR_DEV_NAME, name);
+ if (cmd == VDPA_CMD_DEV_NEW)
+ NLA_PUT_STRING(msg, VDPA_ATTR_MGMTDEV_DEV_NAME, "vduse");
+
+ if (nl_send_sync(nlsock, msg))
+ goto close_sock;
+
+ nl_close(nlsock);
+ nl_socket_free(nlsock);
+
+ return 0;
+ nla_put_failure:
+ nlmsg_free(msg);
+ close_sock:
+ nl_close(nlsock);
+ free_sock:
+ nl_socket_free(nlsock);
+ return -1;
+ }
+
+How VDUSE works
+---------------
+
+As mentioned above, a VDUSE device is created by ioctl(VDUSE_CREATE_DEV) on
+/dev/vduse/control. With this ioctl, userspace can specify some basic configuration
+such as device name (uniquely identify a VDUSE device), virtio features, virtio
+configuration space, the number of virtqueues and so on for this emulated device.
+Then a char device interface (/dev/vduse/$NAME) is exported to userspace for device
+emulation. Userspace can use the VDUSE_VQ_SETUP ioctl on /dev/vduse/$NAME to
+add per-virtqueue configuration such as the max size of virtqueue to the device.
+
+After the initialization, the VDUSE device can be attached to vDPA bus via
+the VDPA_CMD_DEV_NEW netlink message. Userspace needs to read()/write() on
+/dev/vduse/$NAME to receive/reply some control messages from/to VDUSE kernel
+module as follows:
+
+.. code-block:: c
+
+ static int vduse_message_handler(int dev_fd)
+ {
+ int len;
+ struct vduse_dev_request req;
+ struct vduse_dev_response resp;
+
+ len = read(dev_fd, &req, sizeof(req));
+ if (len != sizeof(req))
+ return -1;
+
+ resp.request_id = req.request_id;
+
+ switch (req.type) {
+
+ /* handle different types of messages */
+
+ }
+
+ len = write(dev_fd, &resp, sizeof(resp));
+ if (len != sizeof(resp))
+ return -1;
+
+ return 0;
+ }
+
+There are now three types of messages introduced by VDUSE framework:
+
+- VDUSE_GET_VQ_STATE: Get the state for virtqueue, userspace should return
+ avail index for split virtqueue or the device/driver ring wrap counters and
+ the avail and used index for packed virtqueue.
+
+- VDUSE_SET_STATUS: Set the device status, userspace should follow
+ the virtio spec: https://docs.oasis-open.org/virtio/virtio/v1.1/virtio-v1.1.html
+ to process this message. For example, fail to set the FEATURES_OK device
+ status bit if the device can not accept the negotiated virtio features
+ get from the VDUSE_DEV_GET_FEATURES ioctl.
+
+- VDUSE_UPDATE_IOTLB: Notify userspace to update the memory mapping for specified
+ IOVA range, userspace should firstly remove the old mapping, then setup the new
+ mapping via the VDUSE_IOTLB_GET_FD ioctl.
+
+After DRIVER_OK status bit is set via the VDUSE_SET_STATUS message, userspace is
+able to start the dataplane processing as follows:
+
+1. Get the specified virtqueue's information with the VDUSE_VQ_GET_INFO ioctl,
+ including the size, the IOVAs of descriptor table, available ring and used ring,
+ the state and the ready status.
+
+2. Pass the above IOVAs to the VDUSE_IOTLB_GET_FD ioctl so that those IOVA regions
+ can be mapped into userspace. Some sample codes is shown below:
+
+.. code-block:: c
+
+ static int perm_to_prot(uint8_t perm)
+ {
+ int prot = 0;
+
+ switch (perm) {
+ case VDUSE_ACCESS_WO:
+ prot |= PROT_WRITE;
+ break;
+ case VDUSE_ACCESS_RO:
+ prot |= PROT_READ;
+ break;
+ case VDUSE_ACCESS_RW:
+ prot |= PROT_READ | PROT_WRITE;
+ break;
+ }
+
+ return prot;
+ }
+
+ static void *iova_to_va(int dev_fd, uint64_t iova, uint64_t *len)
+ {
+ int fd;
+ void *addr;
+ size_t size;
+ struct vduse_iotlb_entry entry;
+
+ entry.start = iova;
+ entry.last = iova;
+
+ /*
+ * Find the first IOVA region that overlaps with the specified
+ * range [start, last] and return the corresponding file descriptor.
+ */
+ fd = ioctl(dev_fd, VDUSE_IOTLB_GET_FD, &entry);
+ if (fd < 0)
+ return NULL;
+
+ size = entry.last - entry.start + 1;
+ *len = entry.last - iova + 1;
+ addr = mmap(0, size, perm_to_prot(entry.perm), MAP_SHARED,
+ fd, entry.offset);
+ close(fd);
+ if (addr == MAP_FAILED)
+ return NULL;
+
+ /*
+ * Using some data structures such as linked list to store
+ * the iotlb mapping. The munmap(2) should be called for the
+ * cached mapping when the corresponding VDUSE_UPDATE_IOTLB
+ * message is received or the device is reset.
+ */
+
+ return addr + iova - entry.start;
+ }
+
+3. Setup the kick eventfd for the specified virtqueues with the VDUSE_VQ_SETUP_KICKFD
+ ioctl. The kick eventfd is used by VDUSE kernel module to notify userspace to
+ consume the available ring.
+
+4. Listen to the kick eventfd and consume the available ring. The buffer described
+ by the descriptors in the descriptor table should be also mapped into userspace
+ via the VDUSE_IOTLB_GET_FD ioctl before accessing.
+
+5. Inject an interrupt for specific virtqueue with the VDUSE_INJECT_VQ_IRQ ioctl
+ after the used ring is filled.
+
+For more details on the uAPI, please see include/uapi/linux/vduse.h.
--
2.11.0
^ permalink raw reply related [flat|nested] 55+ messages in thread* Re: [PATCH v10 17/17] Documentation: Add documentation for VDUSE
2021-07-29 7:35 ` [PATCH v10 17/17] Documentation: Add documentation for VDUSE Xie Yongji
@ 2021-08-03 7:35 ` Jason Wang
2021-08-03 8:52 ` Yongji Xie
0 siblings, 1 reply; 55+ messages in thread
From: Jason Wang @ 2021-08-03 7:35 UTC (permalink / raw)
To: Xie Yongji, mst, stefanha, sgarzare, parav, hch,
christian.brauner, rdunlap, willy, viro, axboe, bcrl, corbet,
mika.penttila, dan.carpenter, joro, gregkh, zhe.he, xiaodong.liu,
joe
Cc: songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
在 2021/7/29 下午3:35, Xie Yongji 写道:
> VDUSE (vDPA Device in Userspace) is a framework to support
> implementing software-emulated vDPA devices in userspace. This
> document is intended to clarify the VDUSE design and usage.
>
> Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> ---
> Documentation/userspace-api/index.rst | 1 +
> Documentation/userspace-api/vduse.rst | 232 ++++++++++++++++++++++++++++++++++
> 2 files changed, 233 insertions(+)
> create mode 100644 Documentation/userspace-api/vduse.rst
>
> diff --git a/Documentation/userspace-api/index.rst b/Documentation/userspace-api/index.rst
> index 0b5eefed027e..c432be070f67 100644
> --- a/Documentation/userspace-api/index.rst
> +++ b/Documentation/userspace-api/index.rst
> @@ -27,6 +27,7 @@ place where this information is gathered.
> iommu
> media/index
> sysfs-platform_profile
> + vduse
>
> .. only:: subproject and html
>
> diff --git a/Documentation/userspace-api/vduse.rst b/Documentation/userspace-api/vduse.rst
> new file mode 100644
> index 000000000000..30c9d1482126
> --- /dev/null
> +++ b/Documentation/userspace-api/vduse.rst
> @@ -0,0 +1,232 @@
> +==================================
> +VDUSE - "vDPA Device in Userspace"
> +==================================
> +
> +vDPA (virtio data path acceleration) 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. VDUSE is a framework that makes it
> +possible to implement software-emulated vDPA devices in userspace. And
> +to make the device emulation more secure, the emulated vDPA device's
> +control path is handled in the kernel and only the data path is
> +implemented in the userspace.
> +
> +Note that only virtio block device is supported by VDUSE framework now,
> +which can reduce security risks when the userspace process that implements
> +the data path is run by an unprivileged user. The support for other device
> +types can be added after the security issue of corresponding device driver
> +is clarified or fixed in the future.
> +
> +Create/Destroy VDUSE devices
> +------------------------
> +
> +VDUSE devices are created as follows:
> +
> +1. Create a new VDUSE instance with ioctl(VDUSE_CREATE_DEV) on
> + /dev/vduse/control.
> +
> +2. Setup each virtqueue with ioctl(VDUSE_VQ_SETUP) on /dev/vduse/$NAME.
> +
> +3. Begin processing VDUSE messages from /dev/vduse/$NAME. The first
> + messages will arrive while attaching the VDUSE instance to vDPA bus.
> +
> +4. Send the VDPA_CMD_DEV_NEW netlink message to attach the VDUSE
> + instance to vDPA bus.
> +
> +VDUSE devices are destroyed as follows:
> +
> +1. Send the VDPA_CMD_DEV_DEL netlink message to detach the VDUSE
> + instance from vDPA bus.
> +
> +2. Close the file descriptor referring to /dev/vduse/$NAME.
> +
> +3. Destroy the VDUSE instance with ioctl(VDUSE_DESTROY_DEV) on
> + /dev/vduse/control.
> +
> +The netlink messages can be sent via vdpa tool in iproute2 or use the
> +below sample codes:
> +
> +.. code-block:: c
> +
> + static int netlink_add_vduse(const char *name, enum vdpa_command cmd)
> + {
> + struct nl_sock *nlsock;
> + struct nl_msg *msg;
> + int famid;
> +
> + nlsock = nl_socket_alloc();
> + if (!nlsock)
> + return -ENOMEM;
> +
> + if (genl_connect(nlsock))
> + goto free_sock;
> +
> + famid = genl_ctrl_resolve(nlsock, VDPA_GENL_NAME);
> + if (famid < 0)
> + goto close_sock;
> +
> + msg = nlmsg_alloc();
> + if (!msg)
> + goto close_sock;
> +
> + if (!genlmsg_put(msg, NL_AUTO_PORT, NL_AUTO_SEQ, famid, 0, 0, cmd, 0))
> + goto nla_put_failure;
> +
> + NLA_PUT_STRING(msg, VDPA_ATTR_DEV_NAME, name);
> + if (cmd == VDPA_CMD_DEV_NEW)
> + NLA_PUT_STRING(msg, VDPA_ATTR_MGMTDEV_DEV_NAME, "vduse");
> +
> + if (nl_send_sync(nlsock, msg))
> + goto close_sock;
> +
> + nl_close(nlsock);
> + nl_socket_free(nlsock);
> +
> + return 0;
> + nla_put_failure:
> + nlmsg_free(msg);
> + close_sock:
> + nl_close(nlsock);
> + free_sock:
> + nl_socket_free(nlsock);
> + return -1;
> + }
> +
> +How VDUSE works
> +---------------
> +
> +As mentioned above, a VDUSE device is created by ioctl(VDUSE_CREATE_DEV) on
> +/dev/vduse/control. With this ioctl, userspace can specify some basic configuration
> +such as device name (uniquely identify a VDUSE device), virtio features, virtio
> +configuration space, the number of virtqueues and so on for this emulated device.
> +Then a char device interface (/dev/vduse/$NAME) is exported to userspace for device
> +emulation. Userspace can use the VDUSE_VQ_SETUP ioctl on /dev/vduse/$NAME to
> +add per-virtqueue configuration such as the max size of virtqueue to the device.
> +
> +After the initialization, the VDUSE device can be attached to vDPA bus via
> +the VDPA_CMD_DEV_NEW netlink message. Userspace needs to read()/write() on
> +/dev/vduse/$NAME to receive/reply some control messages from/to VDUSE kernel
> +module as follows:
> +
> +.. code-block:: c
> +
> + static int vduse_message_handler(int dev_fd)
> + {
> + int len;
> + struct vduse_dev_request req;
> + struct vduse_dev_response resp;
> +
> + len = read(dev_fd, &req, sizeof(req));
> + if (len != sizeof(req))
> + return -1;
> +
> + resp.request_id = req.request_id;
> +
> + switch (req.type) {
> +
> + /* handle different types of messages */
> +
> + }
> +
> + len = write(dev_fd, &resp, sizeof(resp));
> + if (len != sizeof(resp))
> + return -1;
> +
> + return 0;
> + }
> +
> +There are now three types of messages introduced by VDUSE framework:
> +
> +- VDUSE_GET_VQ_STATE: Get the state for virtqueue, userspace should return
> + avail index for split virtqueue or the device/driver ring wrap counters and
> + the avail and used index for packed virtqueue.
> +
> +- VDUSE_SET_STATUS: Set the device status, userspace should follow
> + the virtio spec: https://docs.oasis-open.org/virtio/virtio/v1.1/virtio-v1.1.html
> + to process this message. For example, fail to set the FEATURES_OK device
> + status bit if the device can not accept the negotiated virtio features
> + get from the VDUSE_DEV_GET_FEATURES ioctl.
I wonder if it's better to add a section about the future work?
E.g the support for the userspace device to modify status (like
NEEDS_RESET).
> +
> +- VDUSE_UPDATE_IOTLB: Notify userspace to update the memory mapping for specified
> + IOVA range, userspace should firstly remove the old mapping, then setup the new
> + mapping via the VDUSE_IOTLB_GET_FD ioctl.
> +
> +After DRIVER_OK status bit is set via the VDUSE_SET_STATUS message, userspace is
> +able to start the dataplane processing as follows:
> +
> +1. Get the specified virtqueue's information with the VDUSE_VQ_GET_INFO ioctl,
> + including the size, the IOVAs of descriptor table, available ring and used ring,
> + the state and the ready status.
> +
> +2. Pass the above IOVAs to the VDUSE_IOTLB_GET_FD ioctl so that those IOVA regions
> + can be mapped into userspace. Some sample codes is shown below:
> +
> +.. code-block:: c
> +
> + static int perm_to_prot(uint8_t perm)
> + {
> + int prot = 0;
> +
> + switch (perm) {
> + case VDUSE_ACCESS_WO:
> + prot |= PROT_WRITE;
> + break;
> + case VDUSE_ACCESS_RO:
> + prot |= PROT_READ;
> + break;
> + case VDUSE_ACCESS_RW:
> + prot |= PROT_READ | PROT_WRITE;
> + break;
> + }
> +
> + return prot;
> + }
> +
> + static void *iova_to_va(int dev_fd, uint64_t iova, uint64_t *len)
> + {
> + int fd;
> + void *addr;
> + size_t size;
> + struct vduse_iotlb_entry entry;
> +
> + entry.start = iova;
> + entry.last = iova;
> +
> + /*
> + * Find the first IOVA region that overlaps with the specified
> + * range [start, last] and return the corresponding file descriptor.
> + */
> + fd = ioctl(dev_fd, VDUSE_IOTLB_GET_FD, &entry);
> + if (fd < 0)
> + return NULL;
> +
> + size = entry.last - entry.start + 1;
> + *len = entry.last - iova + 1;
> + addr = mmap(0, size, perm_to_prot(entry.perm), MAP_SHARED,
> + fd, entry.offset);
> + close(fd);
> + if (addr == MAP_FAILED)
> + return NULL;
> +
> + /*
> + * Using some data structures such as linked list to store
> + * the iotlb mapping. The munmap(2) should be called for the
> + * cached mapping when the corresponding VDUSE_UPDATE_IOTLB
> + * message is received or the device is reset.
> + */
> +
> + return addr + iova - entry.start;
> + }
> +
> +3. Setup the kick eventfd for the specified virtqueues with the VDUSE_VQ_SETUP_KICKFD
> + ioctl. The kick eventfd is used by VDUSE kernel module to notify userspace to
> + consume the available ring.
> +
> +4. Listen to the kick eventfd and consume the available ring. The buffer described
> + by the descriptors in the descriptor table should be also mapped into userspace
> + via the VDUSE_IOTLB_GET_FD ioctl before accessing.
(Or userspace may poll the indices instead, the kick eventfd is not a must).
Thanks
> +
> +5. Inject an interrupt for specific virtqueue with the VDUSE_INJECT_VQ_IRQ ioctl
> + after the used ring is filled.
> +
> +For more details on the uAPI, please see include/uapi/linux/vduse.h.
^ permalink raw reply [flat|nested] 55+ messages in thread* Re: [PATCH v10 17/17] Documentation: Add documentation for VDUSE
2021-08-03 7:35 ` Jason Wang
@ 2021-08-03 8:52 ` Yongji Xie
0 siblings, 0 replies; 55+ messages in thread
From: Yongji Xie @ 2021-08-03 8:52 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, Stefan Hajnoczi, Stefano Garzarella,
Parav Pandit, Christoph Hellwig, Christian Brauner, Randy Dunlap,
Matthew Wilcox, Al Viro, Jens Axboe, bcrl, Jonathan Corbet,
Mika Penttilä,
Dan Carpenter, joro, Greg KH, He Zhe, Liu Xiaodong, Joe Perches,
songmuchun, virtualization, netdev, kvm, linux-fsdevel, iommu,
linux-kernel
On Tue, Aug 3, 2021 at 3:35 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
> 在 2021/7/29 下午3:35, Xie Yongji 写道:
> > VDUSE (vDPA Device in Userspace) is a framework to support
> > implementing software-emulated vDPA devices in userspace. This
> > document is intended to clarify the VDUSE design and usage.
> >
> > Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> > ---
> > Documentation/userspace-api/index.rst | 1 +
> > Documentation/userspace-api/vduse.rst | 232 ++++++++++++++++++++++++++++++++++
> > 2 files changed, 233 insertions(+)
> > create mode 100644 Documentation/userspace-api/vduse.rst
> >
> > diff --git a/Documentation/userspace-api/index.rst b/Documentation/userspace-api/index.rst
> > index 0b5eefed027e..c432be070f67 100644
> > --- a/Documentation/userspace-api/index.rst
> > +++ b/Documentation/userspace-api/index.rst
> > @@ -27,6 +27,7 @@ place where this information is gathered.
> > iommu
> > media/index
> > sysfs-platform_profile
> > + vduse
> >
> > .. only:: subproject and html
> >
> > diff --git a/Documentation/userspace-api/vduse.rst b/Documentation/userspace-api/vduse.rst
> > new file mode 100644
> > index 000000000000..30c9d1482126
> > --- /dev/null
> > +++ b/Documentation/userspace-api/vduse.rst
> > @@ -0,0 +1,232 @@
> > +==================================
> > +VDUSE - "vDPA Device in Userspace"
> > +==================================
> > +
> > +vDPA (virtio data path acceleration) 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. VDUSE is a framework that makes it
> > +possible to implement software-emulated vDPA devices in userspace. And
> > +to make the device emulation more secure, the emulated vDPA device's
> > +control path is handled in the kernel and only the data path is
> > +implemented in the userspace.
> > +
> > +Note that only virtio block device is supported by VDUSE framework now,
> > +which can reduce security risks when the userspace process that implements
> > +the data path is run by an unprivileged user. The support for other device
> > +types can be added after the security issue of corresponding device driver
> > +is clarified or fixed in the future.
> > +
> > +Create/Destroy VDUSE devices
> > +------------------------
> > +
> > +VDUSE devices are created as follows:
> > +
> > +1. Create a new VDUSE instance with ioctl(VDUSE_CREATE_DEV) on
> > + /dev/vduse/control.
> > +
> > +2. Setup each virtqueue with ioctl(VDUSE_VQ_SETUP) on /dev/vduse/$NAME.
> > +
> > +3. Begin processing VDUSE messages from /dev/vduse/$NAME. The first
> > + messages will arrive while attaching the VDUSE instance to vDPA bus.
> > +
> > +4. Send the VDPA_CMD_DEV_NEW netlink message to attach the VDUSE
> > + instance to vDPA bus.
> > +
> > +VDUSE devices are destroyed as follows:
> > +
> > +1. Send the VDPA_CMD_DEV_DEL netlink message to detach the VDUSE
> > + instance from vDPA bus.
> > +
> > +2. Close the file descriptor referring to /dev/vduse/$NAME.
> > +
> > +3. Destroy the VDUSE instance with ioctl(VDUSE_DESTROY_DEV) on
> > + /dev/vduse/control.
> > +
> > +The netlink messages can be sent via vdpa tool in iproute2 or use the
> > +below sample codes:
> > +
> > +.. code-block:: c
> > +
> > + static int netlink_add_vduse(const char *name, enum vdpa_command cmd)
> > + {
> > + struct nl_sock *nlsock;
> > + struct nl_msg *msg;
> > + int famid;
> > +
> > + nlsock = nl_socket_alloc();
> > + if (!nlsock)
> > + return -ENOMEM;
> > +
> > + if (genl_connect(nlsock))
> > + goto free_sock;
> > +
> > + famid = genl_ctrl_resolve(nlsock, VDPA_GENL_NAME);
> > + if (famid < 0)
> > + goto close_sock;
> > +
> > + msg = nlmsg_alloc();
> > + if (!msg)
> > + goto close_sock;
> > +
> > + if (!genlmsg_put(msg, NL_AUTO_PORT, NL_AUTO_SEQ, famid, 0, 0, cmd, 0))
> > + goto nla_put_failure;
> > +
> > + NLA_PUT_STRING(msg, VDPA_ATTR_DEV_NAME, name);
> > + if (cmd == VDPA_CMD_DEV_NEW)
> > + NLA_PUT_STRING(msg, VDPA_ATTR_MGMTDEV_DEV_NAME, "vduse");
> > +
> > + if (nl_send_sync(nlsock, msg))
> > + goto close_sock;
> > +
> > + nl_close(nlsock);
> > + nl_socket_free(nlsock);
> > +
> > + return 0;
> > + nla_put_failure:
> > + nlmsg_free(msg);
> > + close_sock:
> > + nl_close(nlsock);
> > + free_sock:
> > + nl_socket_free(nlsock);
> > + return -1;
> > + }
> > +
> > +How VDUSE works
> > +---------------
> > +
> > +As mentioned above, a VDUSE device is created by ioctl(VDUSE_CREATE_DEV) on
> > +/dev/vduse/control. With this ioctl, userspace can specify some basic configuration
> > +such as device name (uniquely identify a VDUSE device), virtio features, virtio
> > +configuration space, the number of virtqueues and so on for this emulated device.
> > +Then a char device interface (/dev/vduse/$NAME) is exported to userspace for device
> > +emulation. Userspace can use the VDUSE_VQ_SETUP ioctl on /dev/vduse/$NAME to
> > +add per-virtqueue configuration such as the max size of virtqueue to the device.
> > +
> > +After the initialization, the VDUSE device can be attached to vDPA bus via
> > +the VDPA_CMD_DEV_NEW netlink message. Userspace needs to read()/write() on
> > +/dev/vduse/$NAME to receive/reply some control messages from/to VDUSE kernel
> > +module as follows:
> > +
> > +.. code-block:: c
> > +
> > + static int vduse_message_handler(int dev_fd)
> > + {
> > + int len;
> > + struct vduse_dev_request req;
> > + struct vduse_dev_response resp;
> > +
> > + len = read(dev_fd, &req, sizeof(req));
> > + if (len != sizeof(req))
> > + return -1;
> > +
> > + resp.request_id = req.request_id;
> > +
> > + switch (req.type) {
> > +
> > + /* handle different types of messages */
> > +
> > + }
> > +
> > + len = write(dev_fd, &resp, sizeof(resp));
> > + if (len != sizeof(resp))
> > + return -1;
> > +
> > + return 0;
> > + }
> > +
> > +There are now three types of messages introduced by VDUSE framework:
> > +
> > +- VDUSE_GET_VQ_STATE: Get the state for virtqueue, userspace should return
> > + avail index for split virtqueue or the device/driver ring wrap counters and
> > + the avail and used index for packed virtqueue.
> > +
> > +- VDUSE_SET_STATUS: Set the device status, userspace should follow
> > + the virtio spec: https://docs.oasis-open.org/virtio/virtio/v1.1/virtio-v1.1.html
> > + to process this message. For example, fail to set the FEATURES_OK device
> > + status bit if the device can not accept the negotiated virtio features
> > + get from the VDUSE_DEV_GET_FEATURES ioctl.
>
>
> I wonder if it's better to add a section about the future work?
>
> E.g the support for the userspace device to modify status (like
> NEEDS_RESET).
>
I prefer to document it after we add this new feature.
>
> > +
> > +- VDUSE_UPDATE_IOTLB: Notify userspace to update the memory mapping for specified
> > + IOVA range, userspace should firstly remove the old mapping, then setup the new
> > + mapping via the VDUSE_IOTLB_GET_FD ioctl.
> > +
> > +After DRIVER_OK status bit is set via the VDUSE_SET_STATUS message, userspace is
> > +able to start the dataplane processing as follows:
> > +
> > +1. Get the specified virtqueue's information with the VDUSE_VQ_GET_INFO ioctl,
> > + including the size, the IOVAs of descriptor table, available ring and used ring,
> > + the state and the ready status.
> > +
> > +2. Pass the above IOVAs to the VDUSE_IOTLB_GET_FD ioctl so that those IOVA regions
> > + can be mapped into userspace. Some sample codes is shown below:
> > +
> > +.. code-block:: c
> > +
> > + static int perm_to_prot(uint8_t perm)
> > + {
> > + int prot = 0;
> > +
> > + switch (perm) {
> > + case VDUSE_ACCESS_WO:
> > + prot |= PROT_WRITE;
> > + break;
> > + case VDUSE_ACCESS_RO:
> > + prot |= PROT_READ;
> > + break;
> > + case VDUSE_ACCESS_RW:
> > + prot |= PROT_READ | PROT_WRITE;
> > + break;
> > + }
> > +
> > + return prot;
> > + }
> > +
> > + static void *iova_to_va(int dev_fd, uint64_t iova, uint64_t *len)
> > + {
> > + int fd;
> > + void *addr;
> > + size_t size;
> > + struct vduse_iotlb_entry entry;
> > +
> > + entry.start = iova;
> > + entry.last = iova;
> > +
> > + /*
> > + * Find the first IOVA region that overlaps with the specified
> > + * range [start, last] and return the corresponding file descriptor.
> > + */
> > + fd = ioctl(dev_fd, VDUSE_IOTLB_GET_FD, &entry);
> > + if (fd < 0)
> > + return NULL;
> > +
> > + size = entry.last - entry.start + 1;
> > + *len = entry.last - iova + 1;
> > + addr = mmap(0, size, perm_to_prot(entry.perm), MAP_SHARED,
> > + fd, entry.offset);
> > + close(fd);
> > + if (addr == MAP_FAILED)
> > + return NULL;
> > +
> > + /*
> > + * Using some data structures such as linked list to store
> > + * the iotlb mapping. The munmap(2) should be called for the
> > + * cached mapping when the corresponding VDUSE_UPDATE_IOTLB
> > + * message is received or the device is reset.
> > + */
> > +
> > + return addr + iova - entry.start;
> > + }
> > +
> > +3. Setup the kick eventfd for the specified virtqueues with the VDUSE_VQ_SETUP_KICKFD
> > + ioctl. The kick eventfd is used by VDUSE kernel module to notify userspace to
> > + consume the available ring.
> > +
> > +4. Listen to the kick eventfd and consume the available ring. The buffer described
> > + by the descriptors in the descriptor table should be also mapped into userspace
> > + via the VDUSE_IOTLB_GET_FD ioctl before accessing.
>
>
> (Or userspace may poll the indices instead, the kick eventfd is not a must).
>
OK, will add it.
Thanks,
Yongji
^ permalink raw reply [flat|nested] 55+ messages in thread