On Mon, 24 Feb 2020 14:33:14 +1100
David Gibson wrote:
> On Fri, Feb 21, 2020 at 07:07:02PM +0100, Halil Pasic wrote:
> > On Fri, 21 Feb 2020 10:48:15 -0500
> > "Michael S. Tsirkin" wrote:
> >
> > > On Fri, Feb 21, 2020 at 02:06:39PM +0100, Halil Pasic wrote:
> > > > On Fri, 21 Feb 2020
On Mon, Feb 24, 2020 at 8:26 AM wrote:
>
> From: Anton Ivanov
>
> Some of the locally generated frames marked as GSO which
> arrive at virtio_net_hdr_from_skb() have no GSO_TYPE, no
> fragments (data_len = 0) and length significantly shorter
> than the MTU (752 in my experiments).
Do we
On 24/02/2020 20:20, Willem de Bruijn wrote:
On Mon, Feb 24, 2020 at 2:55 PM Anton Ivanov
wrote:
On 24/02/2020 19:27, Willem de Bruijn wrote:
On Mon, Feb 24, 2020 at 8:26 AM wrote:
From: Anton Ivanov
Some of the locally generated frames marked as GSO which
arrive at
On Sat, Feb 22, 2020 at 02:07:58PM -0500, Michael S. Tsirkin wrote:
> On Fri, Feb 21, 2020 at 03:33:40PM +0100, Halil Pasic wrote:
> > AFAIU you have a positive attitude towards the idea, that
> > !F_VIRTIO_PLATFORM implies 'no DMA API is used by virtio'
> > should be scrapped.
> >
> > I would
On 24/02/2020 19:27, Willem de Bruijn wrote:
On Mon, Feb 24, 2020 at 8:26 AM wrote:
From: Anton Ivanov
Some of the locally generated frames marked as GSO which
arrive at virtio_net_hdr_from_skb() have no GSO_TYPE, no
fragments (data_len = 0) and length significantly shorter
than the MTU
On Mon, Feb 24, 2020 at 2:55 PM Anton Ivanov
wrote:
>
> On 24/02/2020 19:27, Willem de Bruijn wrote:
> > On Mon, Feb 24, 2020 at 8:26 AM wrote:
> >>
> >> From: Anton Ivanov
> >>
> >> Some of the locally generated frames marked as GSO which
> >> arrive at virtio_net_hdr_from_skb() have no
On Fri, 21 Feb 2020 17:36:45 +0100
Christoph Hellwig wrote:
> > By "legacy devices" I assume you mean pre-virtio-1.0 devices, that
> > lack the F_VERSION_1 feature flag. Is that right? Because I don't
> > see how being a legacy device or not relates to use of the DMA API.
>
> No. "legacy"
On 2020/2/24 下午9:56, Halil Pasic wrote:
On Mon, 24 Feb 2020 17:26:20 +0800
Jason Wang wrote:
That's better.
How about attached?
Thanks
Thanks Jason! It does avoid the translation overhead in vhost.
Tested-by: Halil Pasic
Regarding the code, you fence it in virtio-net.c, but AFAIU this
The functions vring_new_virtqueue() and __vring_new_virtqueue() are used
with split rings, and any allocations within these functions are managed
outside of the .we_own_ring flag. The commit cbeedb72b97a ("virtio_ring:
allocate desc state for split ring separately") allocates the desc state
within
On Mon, Feb 24, 2020 at 4:00 PM Anton Ivanov
wrote:
>
> On 24/02/2020 20:20, Willem de Bruijn wrote:
> > On Mon, Feb 24, 2020 at 2:55 PM Anton Ivanov
> > wrote:
> >> On 24/02/2020 19:27, Willem de Bruijn wrote:
> >>> On Mon, Feb 24, 2020 at 8:26 AM wrote:
> From: Anton Ivanov
>
>
On 25/02/2020 04:02, Jason Wang wrote:
On 2020/2/25 上午6:22, Willem de Bruijn wrote:
On Mon, Feb 24, 2020 at 4:00 PM Anton Ivanov
wrote:
On 24/02/2020 20:20, Willem de Bruijn wrote:
On Mon, Feb 24, 2020 at 2:55 PM Anton Ivanov
wrote:
On 24/02/2020 19:27, Willem de Bruijn wrote:
On Mon,
Hi,
> +struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj,
> + int flags)
> +{
[ ... ]
> +}
> +
> +struct drm_gem_object *virtgpu_gem_prime_import(struct drm_device *dev,
> + struct dma_buf *buf)
>
On 24/02/2020 22:22, Willem de Bruijn wrote:
On Mon, Feb 24, 2020 at 4:00 PM Anton Ivanov
wrote:
On 24/02/2020 20:20, Willem de Bruijn wrote:
On Mon, Feb 24, 2020 at 2:55 PM Anton Ivanov
wrote:
On 24/02/2020 19:27, Willem de Bruijn wrote:
On Mon, Feb 24, 2020 at 8:26 AM wrote:
From:
On Wed, Feb 19, 2020 at 05:06:36PM +0900, David Stevens wrote:
> This change adds a new flavor of dma-bufs that can be used by virtio
> drivers to share exported objects. A virtio dma-buf can be queried by
> virtio drivers to obtain the UUID which identifies the underlying
> exported object.
That
On Wed, Feb 19, 2020 at 11:20:40AM +0100, Daniel Vetter wrote:
> With this we can drop the final kfree from the release function.
>
> I also noticed that cirrus forgot to call drm_dev_fini().
>
> v2: Don't call kfree(cirrus) after we've handed overship of that to
> drm_device and the drmm_
On 2020/2/24 下午3:48, Michael S. Tsirkin wrote:
On Mon, Feb 24, 2020 at 02:45:03PM +0800, Jason Wang wrote:
On 2020/2/24 下午2:06, Michael S. Tsirkin wrote:
On Mon, Feb 24, 2020 at 12:01:57PM +0800, Jason Wang wrote:
On 2020/2/21 下午10:56, Halil Pasic wrote:
On Fri, 21 Feb 2020 14:22:26 +0800
On Tue, Feb 18, 2020 at 09:48:15AM +0100, Thomas Zimmermann wrote:
> The qxl driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
>
> v2:
> * rebase onto new simple-encoder interface
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Gerd
On Wed, Feb 19, 2020 at 11:21:01AM +0100, Daniel Vetter wrote:
> With the drm_device lifetime fun cleaned up there's nothing in the way
> anymore to use devm_ for everything hw releated. Do it, and in the
> process, throw out the entire onion unwinding.
>
> Signed-off-by: Daniel Vetter
> Cc:
On Wed, Feb 19, 2020 at 11:21:00AM +0100, Daniel Vetter wrote:
> We can even delete the drm_driver.release hook now!
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: Daniel Vetter
> Cc: "Noralf Trønnes"
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> Cc:
On Wed, Feb 19, 2020 at 11:20:59AM +0100, Daniel Vetter wrote:
> Instead rely on the automatic clean, for which we just need to check
> that drm_mode_config_init succeeded. To avoid an inversion in the
> cleanup we also have to move the dev_private allocation over to
> drmm_kzalloc.
>
>
On 2020/2/24 下午9:40, Michael S. Tsirkin wrote:
Subject: [PATCH] vhost: do not set VIRTIO_F_IOMMU_PLATFORM when IOMMU is not
used
We enable device IOTLB unconditionally when VIRTIO_F_IOMMU_PLATFORM is
negotiated. This lead unnecessary IOTLB miss/update transactions when
IOMMU is used. This
On 2020/2/25 上午6:22, Willem de Bruijn wrote:
On Mon, Feb 24, 2020 at 4:00 PM Anton Ivanov
wrote:
On 24/02/2020 20:20, Willem de Bruijn wrote:
On Mon, Feb 24, 2020 at 2:55 PM Anton Ivanov
wrote:
On 24/02/2020 19:27, Willem de Bruijn wrote:
On Mon, Feb 24, 2020 at 8:26 AM wrote:
From:
On Mon, Feb 24, 2020 at 10:19:12AM +, anton.iva...@cambridgegreys.com wrote:
> From: Anton Ivanov
>
> Some of the locally generated frames marked as GSO which
> arrive at virtio_net_hdr_from_skb() have no GSO_TYPE, no
> fragments (data_len = 0) and length significantly shorter
> than the MTU
On Thu, Feb 20, 2020 at 10:48:33AM +0100, Jiri Slaby wrote:
> On 19. 02. 20, 18:50, Krzysztof Kozlowski wrote:
> > The ioreadX() helpers have inconsistent interface. On some architectures
> > void *__iomem address argument is a pointer to const, on some not.
> >
> > Implementations of ioreadX()
Hi Krzysztof,
On Mon, Feb 24, 2020 at 1:47 PM Krzysztof Kozlowski wrote:
> On Thu, Feb 20, 2020 at 10:48:33AM +0100, Jiri Slaby wrote:
> > On 19. 02. 20, 18:50, Krzysztof Kozlowski wrote:
> > > The ioreadX() helpers have inconsistent interface. On some architectures
> > > void *__iomem address
On 24/02/2020 12:46, Michael S. Tsirkin wrote:
On Mon, Feb 24, 2020 at 10:19:12AM +, anton.iva...@cambridgegreys.com wrote:
From: Anton Ivanov
Some of the locally generated frames marked as GSO which
arrive at virtio_net_hdr_from_skb() have no GSO_TYPE, no
fragments (data_len = 0) and
From: Anton Ivanov
Some of the locally generated frames marked as GSO which
arrive at virtio_net_hdr_from_skb() have no GSO_TYPE, no
fragments (data_len = 0) and length significantly shorter
than the MTU (752 in my experiments).
This is observed on raw sockets reading off vEth interfaces
in all
Hi,
I love your patch! Perhaps something to improve:
[auto build test WARNING on vhost/linux-next]
[also build test WARNING on linus/master ipvs/master v5.6-rc3 next-20200224]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest
On Sun, Feb 23, 2020 at 03:50:25PM +0800, Hillf Danton wrote:
> On Sat, 22 Feb 2020 10:58:12 -0800
> > syzbot found the following crash on:
> >
> > HEAD commit:2bb07f4e tc-testing: updated tdc tests for basic filter
> > git tree: net-next
> > console output:
From: Anton Ivanov
Some of the locally generated frames marked as GSO which
arrive at virtio_net_hdr_from_skb() have no GSO_TYPE, no
fragments (data_len = 0) and length significantly shorter
than the MTU (752 in my experiments).
This is observed on raw sockets reading off vEth interfaces
in all
On Mon, Feb 24, 2020 at 05:26:20PM +0800, Jason Wang wrote:
>
> On 2020/2/24 下午3:48, Michael S. Tsirkin wrote:
> > On Mon, Feb 24, 2020 at 02:45:03PM +0800, Jason Wang wrote:
> > > On 2020/2/24 下午2:06, Michael S. Tsirkin wrote:
> > > > On Mon, Feb 24, 2020 at 12:01:57PM +0800, Jason Wang wrote:
>
On Mon, 24 Feb 2020 17:26:20 +0800
Jason Wang wrote:
> That's better.
>
> How about attached?
>
> Thanks
Thanks Jason! It does avoid the translation overhead in vhost.
Tested-by: Halil Pasic
Regarding the code, you fence it in virtio-net.c, but AFAIU this feature
has relevance for other
From: Geert Uytterhoeven
> Sent: 24 February 2020 12:54
> To: Krzysztof Kozlowski
...
> > > > diff --git a/drivers/net/wireless/ath/ath5k/ahb.c
> > > > b/drivers/net/wireless/ath/ath5k/ahb.c
> > > > index 2c9cec8b53d9..8bd01df369fb 100644
> > > > --- a/drivers/net/wireless/ath/ath5k/ahb.c
> > >
On Mon, Feb 24, 2020 at 01:54:00PM +0100, Geert Uytterhoeven wrote:
> Hi Krzysztof,
>
> On Mon, Feb 24, 2020 at 1:47 PM Krzysztof Kozlowski wrote:
> > On Thu, Feb 20, 2020 at 10:48:33AM +0100, Jiri Slaby wrote:
> > > On 19. 02. 20, 18:50, Krzysztof Kozlowski wrote:
> > > > The ioreadX() helpers
On Mon, 24 Feb 2020 11:08:53 +0100 Stefano Garzarella wrote:
> On Sun, Feb 23, 2020 at 03:50:25PM +0800, Hillf Danton wrote:
> >
> > Seems like vsock needs a word to track lock owner in an attempt to
> > avoid trying to lock sock while the current is the lock owner.
>
> Thanks for this
On Mon, Feb 24, 2020 at 01:25:50PM +, anton.iva...@cambridgegreys.com wrote:
> From: Anton Ivanov
>
> Some of the locally generated frames marked as GSO which
> arrive at virtio_net_hdr_from_skb() have no GSO_TYPE, no
> fragments (data_len = 0) and length significantly shorter
> than the MTU
On 2020/2/25 上午5:26, Suman Anna wrote:
The functions vring_new_virtqueue() and __vring_new_virtqueue() are used
with split rings, and any allocations within these functions are managed
outside of the .we_own_ring flag. The commit cbeedb72b97a ("virtio_ring:
allocate desc state for split ring
37 matches
Mail list logo
