On 2020/5/14 下午5:35, Michael S. Tsirkin wrote:
On Thu, May 14, 2020 at 03:25:49PM +0800, Jason Wang wrote:
We reset IOTLB during device reset this breaks the assumption that the
mapping needs to be controlled via vDPA DMA ops explicitly in a
incremental way. So the networking will be broken aft
From: Stefan Hajnoczi
[ Upstream commit 90b5feb8c4bebc76c27fcaf3e1a0e5ca2d319e9e ]
A userspace process holding a file descriptor to a virtio_blk device can
still invoke block_device_operations after hot unplug. This leads to a
use-after-free accessing vblk->vdev in virtblk_getgeo() when
ioctl(H
From: Stefano Garzarella
[ Upstream commit 107bc0766b9feb5113074c753735a3f115c2141f ]
We want to deliver packets to monitoring devices before it is
put in the virtqueue, to avoid that replies can appear in the
packet capture before the transmitted packet.
Signed-off-by: Stefano Garzarella
Sign
From: Stefan Hajnoczi
[ Upstream commit 90b5feb8c4bebc76c27fcaf3e1a0e5ca2d319e9e ]
A userspace process holding a file descriptor to a virtio_blk device can
still invoke block_device_operations after hot unplug. This leads to a
use-after-free accessing vblk->vdev in virtblk_getgeo() when
ioctl(H
From: Stefano Garzarella
[ Upstream commit 107bc0766b9feb5113074c753735a3f115c2141f ]
We want to deliver packets to monitoring devices before it is
put in the virtqueue, to avoid that replies can appear in the
packet capture before the transmitted packet.
Signed-off-by: Stefano Garzarella
Sign
From: Stefano Garzarella
[ Upstream commit 107bc0766b9feb5113074c753735a3f115c2141f ]
We want to deliver packets to monitoring devices before it is
put in the virtqueue, to avoid that replies can appear in the
packet capture before the transmitted packet.
Signed-off-by: Stefano Garzarella
Sign
From: Stefan Hajnoczi
[ Upstream commit 90b5feb8c4bebc76c27fcaf3e1a0e5ca2d319e9e ]
A userspace process holding a file descriptor to a virtio_blk device can
still invoke block_device_operations after hot unplug. This leads to a
use-after-free accessing vblk->vdev in virtblk_getgeo() when
ioctl(H
From: Stefan Hajnoczi
[ Upstream commit 90b5feb8c4bebc76c27fcaf3e1a0e5ca2d319e9e ]
A userspace process holding a file descriptor to a virtio_blk device can
still invoke block_device_operations after hot unplug. This leads to a
use-after-free accessing vblk->vdev in virtblk_getgeo() when
ioctl(H
From: Stefano Garzarella
[ Upstream commit 107bc0766b9feb5113074c753735a3f115c2141f ]
We want to deliver packets to monitoring devices before it is
put in the virtqueue, to avoid that replies can appear in the
packet capture before the transmitted packet.
Signed-off-by: Stefano Garzarella
Sign
Hi,
Many vhost drivers follow a common process to obtain and verify
received buffers:
head = vhost_get_vq_desc(vq, vq->iov, ARRAY_SIZE(vq->iov), &out, &in,...);
if (head < 0) {
return ret;
}
if (head == vq->num) {
/* no buffer */
return 0; /* or -EAGAIN or whatever */
}
i
On Thu, May 14, 2020 at 09:59:52AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > - for the runtime upcasting the usual approach is to check the ->ops
> > pointer. Which means that would need to be the same for all virtio
> > dma_bufs, which might get a bit awkward. But I'd really prefer we not
> > add
On Thu, May 14, 2020 at 05:19:40PM +0900, David Stevens wrote:
> Sorry for the duplicate reply, didn't notice this until now.
>
> > Just storing
> > the uuid should be doable (assuming this doesn't change during the
> > lifetime of the buffer), so no need for a callback.
>
> Directly storing the
On Thu, May 14, 2020 at 11:08:52AM +0900, David Stevens wrote:
> On Thu, May 14, 2020 at 12:45 AM Daniel Vetter wrote:
> > On Wed, Mar 11, 2020 at 12:20 PM David Stevens
> > wrote:
> > >
> > > This change adds a new dma-buf operation that allows dma-bufs to be used
> > > by virtio drivers to sha
On 14.05.20 13:47, David Hildenbrand wrote:
> On 14.05.20 13:10, David Hildenbrand wrote:
>> On 14.05.20 12:12, David Hildenbrand wrote:
>>> On 14.05.20 12:02, teawater wrote:
> 2020年5月14日 16:48，David Hildenbrand 写道：
>
> On 14.05.20 08:44, teawater wrote:
>> Hi David,
>>>
On 14.05.20 13:10, David Hildenbrand wrote:
> On 14.05.20 12:12, David Hildenbrand wrote:
>> On 14.05.20 12:02, teawater wrote:
>>>
>>>
2020年5月14日 16:48，David Hildenbrand 写道：
On 14.05.20 08:44, teawater wrote:
> Hi David,
>
> I got a kernel warning with v2 and v3.
>
On 14.05.20 12:12, David Hildenbrand wrote:
> On 14.05.20 12:02, teawater wrote:
>>
>>
>>> 2020年5月14日 16:48，David Hildenbrand 写道：
>>>
>>> On 14.05.20 08:44, teawater wrote:
Hi David,
I got a kernel warning with v2 and v3.
>>>
>>> Hi Hui,
>>>
>>> thanks for playing with the latest ve
On Thu, May 14, 2020 at 12:50:16PM +0200, Jean-Philippe Brucker wrote:
> On Thu, May 14, 2020 at 05:31:00AM -0400, Michael S. Tsirkin wrote:
> > On Thu, May 14, 2020 at 01:22:37PM +0530, Bharat Bhushan wrote:
> > > Different endpoint can support different page size, probe
> > > endpoint if it suppo
On Thu, May 14, 2020 at 05:31:00AM -0400, Michael S. Tsirkin wrote:
> On Thu, May 14, 2020 at 01:22:37PM +0530, Bharat Bhushan wrote:
> > Different endpoint can support different page size, probe
> > endpoint if it supports specific page size otherwise use
> > global page sizes.
> >
> > Device att
On 14.05.20 12:02, teawater wrote:
>
>
>> 2020年5月14日 16:48，David Hildenbrand 写道：
>>
>> On 14.05.20 08:44, teawater wrote:
>>> Hi David,
>>>
>>> I got a kernel warning with v2 and v3.
>>
>> Hi Hui,
>>
>> thanks for playing with the latest versions. Surprisingly, I can
>> reproduce even by hotplug
On Thu, May 14, 2020 at 03:25:49PM +0800, Jason Wang wrote:
> We reset IOTLB during device reset this breaks the assumption that the
> mapping needs to be controlled via vDPA DMA ops explicitly in a
> incremental way. So the networking will be broken after e.g a guest
> reset.
>
> Fix this by not
On Thu, May 14, 2020 at 01:22:37PM +0530, Bharat Bhushan wrote:
> Different endpoint can support different page size, probe
> endpoint if it supports specific page size otherwise use
> global page sizes.
>
> Device attached to domain should support a minimum of
> domain supported page sizes. If de
On 14.05.20 08:44, teawater wrote:
> Hi David,
>
> I got a kernel warning with v2 and v3.
Hi Hui,
thanks for playing with the latest versions. Surprisingly, I can
reproduce even by hotplugging a DIMM instead as well - that's good, so
it's not related to virtio-mem, lol. Seems to be some QEMU set
Hi,
> - for the runtime upcasting the usual approach is to check the ->ops
> pointer. Which means that would need to be the same for all virtio
> dma_bufs, which might get a bit awkward. But I'd really prefer we not
> add allocator specific stuff like this to dma-buf.
This is exactly the proble
Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> drm_gem_shmem_get_sg_table is meant to implement
> obj->funcs->get_sg_table, for prime exporting. The one we want is
> drm_gem_shmem_get_pages_sgt, which also handles imported dma-buf, not
> just native objects.
>
> v2: Rebase, this stuff moved aroun
We reset IOTLB during device reset this breaks the assumption that the
mapping needs to be controlled via vDPA DMA ops explicitly in a
incremental way. So the networking will be broken after e.g a guest
reset.
Fix this by not resetting the IOTLB during device reset.
Signed-off-by: Jason Wang
---
25 matches
Mail list logo
