search for: userpsac

This feature bit is duplicated with VIRTIO_F_ANY_LAYOUT, this means if a userpsace want to enable VRITIO_F_ANY_LAYOUT, VHOST_NET_F_VIRTIO_NET_HDR will be implied too. This is wrong and will break networking. Fixing this by safely removing VHOST_NET_F_VIRTIO_NET_HDR support. There should be very few or even no userspace can use this. Further cleanups could be done for -net-next f...

This feature bit is duplicated with VIRTIO_F_ANY_LAYOUT, this means if a userpsace want to enable VRITIO_F_ANY_LAYOUT, VHOST_NET_F_VIRTIO_NET_HDR will be implied too. This is wrong and will break networking. Fixing this by safely removing VHOST_NET_F_VIRTIO_NET_HDR support. There should be very few or even no userspace can use this. Further cleanups could be done for -net-next f...

On 2018?06?08? 12:46, Michael S. Tsirkin wrote: > On Fri, Jun 08, 2018 at 11:50:42AM +0800, Jason Wang wrote: >> This feature bit is duplicated with VIRTIO_F_ANY_LAYOUT, this means if >> a userpsace want to enable VRITIO_F_ANY_LAYOUT, >> VHOST_NET_F_VIRTIO_NET_HDR will be implied too. This is wrong and will >> break networking. > What breaks networking exactly? VHOST_NET supported ANY_LAYOUT > from day one. For this reason it does not need to know about > VRITIO_F_ANY_LAY...

On 2018?06?08? 12:46, Michael S. Tsirkin wrote: > On Fri, Jun 08, 2018 at 11:50:42AM +0800, Jason Wang wrote: >> This feature bit is duplicated with VIRTIO_F_ANY_LAYOUT, this means if >> a userpsace want to enable VRITIO_F_ANY_LAYOUT, >> VHOST_NET_F_VIRTIO_NET_HDR will be implied too. This is wrong and will >> break networking. > What breaks networking exactly? VHOST_NET supported ANY_LAYOUT > from day one. For this reason it does not need to know about > VRITIO_F_ANY_LAY...

..., Jun 08, 2018 at 01:07:09PM +0800, Jason Wang wrote: >> >> On 2018?06?08? 12:46, Michael S. Tsirkin wrote: >>> On Fri, Jun 08, 2018 at 11:50:42AM +0800, Jason Wang wrote: >>>> This feature bit is duplicated with VIRTIO_F_ANY_LAYOUT, this means if >>>> a userpsace want to enable VRITIO_F_ANY_LAYOUT, >>>> VHOST_NET_F_VIRTIO_NET_HDR will be implied too. This is wrong and will >>>> break networking. >>> What breaks networking exactly? VHOST_NET supported ANY_LAYOUT >>> from day one. For this reason it does not need to...

...y giving up on fixing the tools and or the drivers themselves to be architected differently (see #2 above). That really isn't acceptable in my opinion. > The intention of my patch with the IFF_HIDDEN attribute is: > 1. it is a netdev attribute > > 2. that attribute can be used by userpsace to indicate to the kernel I > want all or I want the default > > 3. that attribute can be controlled by an admin. > > The patches go beyond my specific use case (preventing a user from > modifying a netdev it should not be touching) but to defining the > semantics of a gener...

On Fri, Jun 08, 2018 at 11:50:42AM +0800, Jason Wang wrote: > This feature bit is duplicated with VIRTIO_F_ANY_LAYOUT, this means if > a userpsace want to enable VRITIO_F_ANY_LAYOUT, > VHOST_NET_F_VIRTIO_NET_HDR will be implied too. This is wrong and will > break networking. What breaks networking exactly? VHOST_NET supported ANY_LAYOUT from day one. For this reason it does not need to know about VRITIO_F_ANY_LAYOUT and we reused the...

...name as the prefix as opposed to "eth" or ":eth". And we don't need to have auto-managed netdevs locked into the ":" prefix at all (I intentionally left it out in the this RFC patch to ask for comments on the namespace solution which is much cleaner). That said, an userpsace named device through udev may call something like ens3 and switch1-port2, but in the kernel-net namespace, it may look like ixgbevf0 and mlxsw1p2. So if we all agree introducing a new namespace is the rigth thing to do, `ip link' will no longer serve the purpose of displaying the information...

On Fri, Jun 08, 2018 at 01:07:09PM +0800, Jason Wang wrote: > > > On 2018?06?08? 12:46, Michael S. Tsirkin wrote: > > On Fri, Jun 08, 2018 at 11:50:42AM +0800, Jason Wang wrote: > > > This feature bit is duplicated with VIRTIO_F_ANY_LAYOUT, this means if > > > a userpsace want to enable VRITIO_F_ANY_LAYOUT, > > > VHOST_NET_F_VIRTIO_NET_HDR will be implied too. This is wrong and will > > > break networking. > > What breaks networking exactly? VHOST_NET supported ANY_LAYOUT > > from day one. For this reason it does not need to know about...

...wise move. > > > > Just thought I'd point it out. > > The drm_syncobj_put() doesn't call replace/reset fence until syncobj is > freed. We drop the old fence for active/alive in-syncobj here after > handling the fence-wait, this makes syncobj reusable, otherwise > userpsace would have to re-create syncobjs after each submission. > I see, thanks. > >> > >> + ret = virtio_gpu_parse_deps(&submit); > >> + if (ret) > >> + goto cleanup; > >> + > >> + ret = virtio_gpu_parse_post_deps(&sub...

From: David Ahern <dsahern at gmail.com> Date: Wed, 4 Apr 2018 11:21:54 -0600 > It is a netdev so there is no reason to have a separate ip command to > inspect it. 'ip link' is the right place. I agree on this. What I really don't understand still is the use case... really. So there are control netdevs, what exactly is the problem with that? Are we not exporting enough

From: David Ahern <dsahern at gmail.com> Date: Wed, 4 Apr 2018 11:21:54 -0600 > It is a netdev so there is no reason to have a separate ip command to > inspect it. 'ip link' is the right place. I agree on this. What I really don't understand still is the use case... really. So there are control netdevs, what exactly is the problem with that? Are we not exporting enough

This introduces vringh, which are generic accessors for virtio rings (host side). There's a host-side implementation in vhost, but it assumes that the rings are in userspace, and is tied to the vhost implementation. I have patches to adapt it to use vringh, but I'm pushing this in the next merge window for Sjur, who has CAIF patches which need it. This also includes a test program in

This introduces vringh, which are generic accessors for virtio rings (host side). There's a host-side implementation in vhost, but it assumes that the rings are in userspace, and is tied to the vhost implementation. I have patches to adapt it to use vringh, but I'm pushing this in the next merge window for Sjur, who has CAIF patches which need it. This also includes a test program in

Getting use of virtio rings correct is tricky, and a recent patch saw an implementation of in-kernel rings (as separate from userspace). This patch attempts to abstract the business of dealing with the virtio ring layout from the access (userspace or direct); to do this, we use function pointers, which gcc inlines correctly. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> ---

Getting use of virtio rings correct is tricky, and a recent patch saw an implementation of in-kernel rings (as separate from userspace). This patch attempts to abstract the business of dealing with the virtio ring layout from the access (userspace or direct); to do this, we use function pointers, which gcc inlines correctly. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> ---