Re: [PATCH] vdpa: Add support for no-IOMMU mode

2024-05-30 Thread Jason Wang
On Thu, May 30, 2024 at 6:18 PM Srujana Challa wrote: > > This commit introduces support for an UNSAFE, no-IOMMU mode in the > vhost-vdpa driver. When enabled, this mode provides no device isolation, > no DMA translation, no host kernel protection, and cannot be used for > device assignment to vir

Re: [PATCH] fuse: cleanup request queuing towards virtiofs

2024-05-30 Thread Bernd Schubert
On 5/30/24 11:00, Miklos Szeredi wrote: > On Thu, 30 May 2024 at 05:20, Jingbo Xu wrote: > >>> + if (test_bit(FR_FINISHED, &req->flags)) { >>> + list_del_init(&req->intr_entry); >>> + spin_unlock(&fiq->lock ^ >>

Re: [RFC] Legacy Virtio Driver with Device Has Limited Memory Access

2024-05-30 Thread Michael S. Tsirkin
On Thu, May 16, 2024 at 02:59:13PM +0200, Manivannan Sadhasivam wrote: > We can fix the endpoint framework limitation, but the problem lies with some > platforms where we cannot write to vendor capability registers and still have > IOMMU. What exactly do you mean? Why do you need to write to vendo

Re: [PATCH] fuse: cleanup request queuing towards virtiofs

2024-05-30 Thread Jingbo Xu
On 5/30/24 5:00 PM, Miklos Szeredi wrote: > On Thu, 30 May 2024 at 05:20, Jingbo Xu wrote: > >>> + if (test_bit(FR_FINISHED, &req->flags)) { >>> + list_del_init(&req->intr_entry); >>> + spin_unlock(&fiq->lock ^ >>

Re: [RFC] Legacy Virtio Driver with Device Has Limited Memory Access

2024-05-30 Thread Manivannan Sadhasivam
On Mon, May 20, 2024 at 07:24:32PM +0900, Shunsuke Mie wrote: > 2024年5月16日(木) 21:59 Manivannan Sadhasivam : > > > > On Thu, May 16, 2024 at 01:38:40PM +0900, Shunsuke Mie wrote: > > > Hi virtio folks, > > > > > > > You forgot to CC the actual Virtio folks. I've CCed them now. > Oops. thank you. > >

Re: [PATCH] fuse: cleanup request queuing towards virtiofs

2024-05-30 Thread Peter-Jan Gootzen
On Wed, 2024-05-29 at 14:32 -0400, Stefan Hajnoczi wrote: > On Wed, May 29, 2024 at 05:52:07PM +0200, Miklos Szeredi wrote: > > Virtiofs has its own queing mechanism, but still requests are first > > queued > > on fiq->pending to be immediately dequeued and queued onto the > > virtio > > queue. > >

[PATCH] vdpa: Add support for no-IOMMU mode

2024-05-30 Thread Srujana Challa
This commit introduces support for an UNSAFE, no-IOMMU mode in the vhost-vdpa driver. When enabled, this mode provides no device isolation, no DMA translation, no host kernel protection, and cannot be used for device assignment to virtual machines. It requires RAWIO permissions and will taint the k

virtio-fs tests between host(x86) and dpu(arm64)

2024-05-30 Thread Lege Wang
Hello, I see that you have added multi-queue support for virtio-fs, thanks for this work. From your patch's commit log, your host is x86-64, dpu is arm64, but there're differences about O_DIRECT and O_DIRECTORY between these two architectures. Test program: #define _GNU_SOURCE #include #includ

Re: [PATCH] fuse: cleanup request queuing towards virtiofs

2024-05-30 Thread Miklos Szeredi
On Wed, 29 May 2024 at 20:32, Stefan Hajnoczi wrote: > This is a little scary but I can't think of a scenario where directly > dispatching requests to virtqueues is a problem. It would be scary if it was't a simple transformation: insert element on empty list, remove only element from list -> d

Re: [PATCH] fuse: cleanup request queuing towards virtiofs

2024-05-30 Thread Miklos Szeredi
On Thu, 30 May 2024 at 05:20, Jingbo Xu wrote: > > + if (test_bit(FR_FINISHED, &req->flags)) { > > + list_del_init(&req->intr_entry); > > + spin_unlock(&fiq->lock ^ > missing "return" here? Well spotted. Thanks