search for: userspace

...; > >> >> >Or drop IFF_FAILOVER_SLAVE and set both IFF_FAILOVER and IFF_SLAVE? > >> >> > >> >> No. IFF_SLAVE is for bonding. > >> > > >> >What breaks if we reuse it for failover? > >> > >> This is exposed to userspace. IFF_SLAVE is expected for bonding slaves. > >> And failover slave is not a bonding slave. > > > >That does not really answer the question. I'd claim it's sufficiently > >like a bond slave for IFF_SLAVE to make sense. > > > >In fact you will find that...

...; > >> >> >Or drop IFF_FAILOVER_SLAVE and set both IFF_FAILOVER and IFF_SLAVE? > >> >> > >> >> No. IFF_SLAVE is for bonding. > >> > > >> >What breaks if we reuse it for failover? > >> > >> This is exposed to userspace. IFF_SLAVE is expected for bonding slaves. > >> And failover slave is not a bonding slave. > > > >That does not really answer the question. I'd claim it's sufficiently > >like a bond slave for IFF_SLAVE to make sense. > > > >In fact you will find that...

Replace `userpace` with `userspace`. Cc: Simon Horman <simon.horman at corigine.com> Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- drivers/vhost/vringh.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/vhost/vringh.c b/drivers/vhost/vringh.c index a1e27da5...

...E and set both IFF_FAILOVER and IFF_SLAVE? > >> >> >> > >> >> >> No. IFF_SLAVE is for bonding. > >> >> > > >> >> >What breaks if we reuse it for failover? > >> >> > >> >> This is exposed to userspace. IFF_SLAVE is expected for bonding slaves. > >> >> And failover slave is not a bonding slave. > >> > > >> >That does not really answer the question. I'd claim it's sufficiently > >> >like a bond slave for IFF_SLAVE to make sense. > >...

...E and set both IFF_FAILOVER and IFF_SLAVE? > >> >> >> > >> >> >> No. IFF_SLAVE is for bonding. > >> >> > > >> >> >What breaks if we reuse it for failover? > >> >> > >> >> This is exposed to userspace. IFF_SLAVE is expected for bonding slaves. > >> >> And failover slave is not a bonding slave. > >> > > >> >That does not really answer the question. I'd claim it's sufficiently > >> >like a bond slave for IFF_SLAVE to make sense. > >...

Add QEMU support for the KVM balloon driver. Memory hinting is performed via madvise(). Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Index: kvm-userspace/libkvm/libkvm.c =================================================================== --- kvm-userspace.orig/libkvm/libkvm.c +++ kvm-userspace/libkvm/libkvm.c @@ -886,6 +886,17 @@ int kvm_is_ready_for_interrupt_injection return run->ready_for_interrupt_injection; } +int kvm_sync_shadow_with_u...

Add QEMU support for the KVM balloon driver. Memory hinting is performed via madvise(). Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Index: kvm-userspace/libkvm/libkvm.c =================================================================== --- kvm-userspace.orig/libkvm/libkvm.c +++ kvm-userspace/libkvm/libkvm.c @@ -886,6 +886,17 @@ int kvm_is_ready_for_interrupt_injection return run->ready_for_interrupt_injection; } +int kvm_sync_shadow_with_u...

...Tue, 26 Mar 2019 19:48:13 -0400 Si-Wei Liu <si-wei.liu at oracle.com> wrote: > When a netdev appears through hot plug then gets enslaved by a failover > master that is already up and running, the slave will be opened > right away after getting enslaved. Today there's a race that userspace > (udev) may fail to rename the slave if the kernel (net_failover) > opens the slave earlier than when the userspace rename happens. > Unlike bond or team, the primary slave of failover can't be renamed by > userspace ahead of time, since the kernel initiated auto-enslavement is &gt...

...Tue, 26 Mar 2019 19:48:13 -0400 Si-Wei Liu <si-wei.liu at oracle.com> wrote: > When a netdev appears through hot plug then gets enslaved by a failover > master that is already up and running, the slave will be opened > right away after getting enslaved. Today there's a race that userspace > (udev) may fail to rename the slave if the kernel (net_failover) > opens the slave earlier than when the userspace rename happens. > Unlike bond or team, the primary slave of failover can't be renamed by > userspace ahead of time, since the kernel initiated auto-enslavement is &gt...

...d the virtio-net netdev are owned by the virtio-net PCI driver). >>>> >>>> Cloud-init should really just ignore all devices that have a master device. >>>> That would have been more general, and safer for other use cases. >>> >>> Given lots of userspace doesn't do this, I wonder whether it would be >>> safer to just somehow pretend to userspace that the slave links are >>> down? And add a special attribute for the actual link state. >> >> I think this may be problematic as it would also break legit use case >&...

...d the virtio-net netdev are owned by the virtio-net PCI driver). >>>> >>>> Cloud-init should really just ignore all devices that have a master device. >>>> That would have been more general, and safer for other use cases. >>> >>> Given lots of userspace doesn't do this, I wonder whether it would be >>> safer to just somehow pretend to userspace that the slave links are >>> down? And add a special attribute for the actual link state. >> >> I think this may be problematic as it would also break legit use case >&...

On Wed, Mar 06, 2019 at 10:08:32PM -0500, Si-Wei Liu wrote: > When a netdev appears through hot plug then gets enslaved by a failover > master that is already up and running, the slave will be opened > right away after getting enslaved. Today there's a race that userspace > (udev) may fail to rename the slave if the kernel (net_failover) > opens the slave earlier than when the userspace rename happens. > Unlike bond or team, the primary slave of failover can't be renamed by > userspace ahead of time, since the kernel initiated auto-enslavement is &gt...

On Wed, Mar 06, 2019 at 10:08:32PM -0500, Si-Wei Liu wrote: > When a netdev appears through hot plug then gets enslaved by a failover > master that is already up and running, the slave will be opened > right away after getting enslaved. Today there's a race that userspace > (udev) may fail to rename the slave if the kernel (net_failover) > opens the slave earlier than when the userspace rename happens. > Unlike bond or team, the primary slave of failover can't be renamed by > userspace ahead of time, since the kernel initiated auto-enslavement is &gt...

...do backport. >> > > > > >> > > > >Plus, DPDK is now dependent on existing model. >> > > > >> > > > Sorry, but nobody here cares about dpdk or other similar oddities. >> > > >> > > The network device model is a userspace API, and DPDK is a userspace application. >> > >> > It is userspace but are you sure dpdk is actually poking at netdevs? >> > AFAIK it's normally banging device registers directly. >> > >> > > You can't go breaking userspace even if you don...

...do backport. >> > > > > >> > > > >Plus, DPDK is now dependent on existing model. >> > > > >> > > > Sorry, but nobody here cares about dpdk or other similar oddities. >> > > >> > > The network device model is a userspace API, and DPDK is a userspace application. >> > >> > It is userspace but are you sure dpdk is actually poking at netdevs? >> > AFAIK it's normally banging device registers directly. >> > >> > > You can't go breaking userspace even if you don...

...virtio-net PCI driver). >>>>>> >>>>>> Cloud-init should really just ignore all devices that have a master device. >>>>>> That would have been more general, and safer for other use cases. >>>>> >>>>> Given lots of userspace doesn't do this, I wonder whether it would be >>>>> safer to just somehow pretend to userspace that the slave links are >>>>> down? And add a special attribute for the actual link state. >>>> >>>> I think this may be problematic as it would...

...virtio-net PCI driver). >>>>>> >>>>>> Cloud-init should really just ignore all devices that have a master device. >>>>>> That would have been more general, and safer for other use cases. >>>>> >>>>> Given lots of userspace doesn't do this, I wonder whether it would be >>>>> safer to just somehow pretend to userspace that the slave links are >>>>> down? And add a special attribute for the actual link state. >>>> >>>> I think this may be problematic as it would...

On Wed, Apr 03, 2019 at 12:52:47AM -0400, Si-Wei Liu wrote: > When a netdev appears through hot plug then gets enslaved by a failover > master that is already up and running, the slave will be opened > right away after getting enslaved. Today there's a race that userspace > (udev) may fail to rename the slave if the kernel (net_failover) > opens the slave earlier than when the userspace rename happens. > Unlike bond or team, the primary slave of failover can't be renamed by > userspace ahead of time, since the kernel initiated auto-enslavement is &gt...

On Wed, Apr 03, 2019 at 12:52:47AM -0400, Si-Wei Liu wrote: > When a netdev appears through hot plug then gets enslaved by a failover > master that is already up and running, the slave will be opened > right away after getting enslaved. Today there's a race that userspace > (udev) may fail to rename the slave if the kernel (net_failover) > opens the slave earlier than when the userspace rename happens. > Unlike bond or team, the primary slave of failover can't be renamed by > userspace ahead of time, since the kernel initiated auto-enslavement is &gt...

...ans we really can't have a new model; or do backport. > > > > > > > >Plus, DPDK is now dependent on existing model. > > > > > > Sorry, but nobody here cares about dpdk or other similar oddities. > > > > The network device model is a userspace API, and DPDK is a userspace application. > > It is userspace but are you sure dpdk is actually poking at netdevs? > AFAIK it's normally banging device registers directly. > > > You can't go breaking userspace even if you don't like the application. > > Co...