search for: vsock_cor

These patches try to handle the hot-unplug of vsock virtio transport device in a proper way. Maybe move the vsock_core_init()/vsock_core_exit() functions in the module_init and module_exit of vsock_virtio_transport module can't be the best way, but the architecture of vsock_core forces us to this approach for now. The vsock_core proto_ops expect a valid pointer to the transport device, so we can't call vs...

These patches try to handle the hot-unplug of vsock virtio transport device in a proper way. Maybe move the vsock_core_init()/vsock_core_exit() functions in the module_init and module_exit of vsock_virtio_transport module can't be the best way, but the architecture of vsock_core forces us to this approach for now. The vsock_core proto_ops expect a valid pointer to the transport device, so we can't call vs...

From: Stefano Garzarella <sgarzare at redhat.com> Date: Fri, 1 Feb 2019 12:42:05 +0100 > These patches try to handle the hot-unplug of vsock virtio transport device in > a proper way. > > Maybe move the vsock_core_init()/vsock_core_exit() functions in the module_init > and module_exit of vsock_virtio_transport module can't be the best way, but the > architecture of vsock_core forces us to this approach for now. > > The vsock_core proto_ops expect a valid pointer to the transport device, so...

...; > > So, I should refactor the functions that can be called also from the vsock > > core, in order to remove "struct net_device *dev" parameter. > > Maybe creating some wrappers for the network stack. > > > > Otherwise I should create a fake net_device for vsock_core. > > > > What do you suggest? > > Neither. > > I think what Jason was saying all along is this: > > virtio net doesn't actually lose packets, at least most > of the time. And it actually most of the time > passes all packets to host. So it's possible...

...; > > So, I should refactor the functions that can be called also from the vsock > > core, in order to remove "struct net_device *dev" parameter. > > Maybe creating some wrappers for the network stack. > > > > Otherwise I should create a fake net_device for vsock_core. > > > > What do you suggest? > > Neither. > > I think what Jason was saying all along is this: > > virtio net doesn't actually lose packets, at least most > of the time. And it actually most of the time > passes all packets to host. So it's possible...

...t; go for vsock core? > Yes, that should work. So, I should refactor the functions that can be called also from the vsock core, in order to remove "struct net_device *dev" parameter. Maybe creating some wrappers for the network stack. Otherwise I should create a fake net_device for vsock_core. What do you suggest? > > > > > > > > > We can use the virtio-net as transport, but we should add a lot of > > > > code to skip "net device" stuff when it is used by the virtio-vsock. > > > This could be another choice, but consider i...

...t; go for vsock core? > Yes, that should work. So, I should refactor the functions that can be called also from the vsock core, in order to remove "struct net_device *dev" parameter. Maybe creating some wrappers for the network stack. Otherwise I should create a fake net_device for vsock_core. What do you suggest? > > > > > > > > > We can use the virtio-net as transport, but we should add a lot of > > > > code to skip "net device" stuff when it is used by the virtio-vsock. > > > This could be another choice, but consider i...

...io_transport.c > > > @@ -702,28 +702,27 @@ static int __init virtio_vsock_init(void) > > > if (!virtio_vsock_workqueue) > > > return -ENOMEM; > > > > > > - ret = register_virtio_driver(&virtio_vsock_driver); > > > + ret = vsock_core_init(&virtio_transport.transport); > > > > Have you checked that all transport callbacks are safe even if another > > CPU calls them while virtio_vsock_probe() is executing on another CPU? > > > > I have the same doubt. > > What do you think to take the '...

...@ static int __init virtio_vsock_init(void) > > > > > if (!virtio_vsock_workqueue) > > > > > return -ENOMEM; > > > > > > > > > > - ret = register_virtio_driver(&virtio_vsock_driver); > > > > > + ret = vsock_core_init(&virtio_transport.transport); > > > > > > > > Have you checked that all transport callbacks are safe even if another > > > > CPU calls them while virtio_vsock_probe() is executing on another CPU? > > > > > > > > > > I have...

...@ static int __init virtio_vsock_init(void) > > > > > if (!virtio_vsock_workqueue) > > > > > return -ENOMEM; > > > > > > > > > > - ret = register_virtio_driver(&virtio_vsock_driver); > > > > > + ret = vsock_core_init(&virtio_transport.transport); > > > > > > > > Have you checked that all transport callbacks are safe even if another > > > > CPU calls them while virtio_vsock_probe() is executing on another CPU? > > > > > > > > > > I have...

...Yes, that should work. > > So, I should refactor the functions that can be called also from the vsock > core, in order to remove "struct net_device *dev" parameter. > Maybe creating some wrappers for the network stack. > > Otherwise I should create a fake net_device for vsock_core. > > What do you suggest? I'm not quite sure I get the question. Can you just use the one that created by virtio_net? Thanks

...nsport.c > > +++ b/net/vmw_vsock/virtio_transport.c > > @@ -702,28 +702,27 @@ static int __init virtio_vsock_init(void) > > if (!virtio_vsock_workqueue) > > return -ENOMEM; > > > > - ret = register_virtio_driver(&virtio_vsock_driver); > > + ret = vsock_core_init(&virtio_transport.transport); > > Have you checked that all transport callbacks are safe even if another > CPU calls them while virtio_vsock_probe() is executing on another CPU? > I have the same doubt. What do you think to take the 'the_virtio_vsock_mutex' in the...

...nsport.c > > +++ b/net/vmw_vsock/virtio_transport.c > > @@ -702,28 +702,27 @@ static int __init virtio_vsock_init(void) > > if (!virtio_vsock_workqueue) > > return -ENOMEM; > > > > - ret = register_virtio_driver(&virtio_vsock_driver); > > + ret = vsock_core_init(&virtio_transport.transport); > > Have you checked that all transport callbacks are safe even if another > CPU calls them while virtio_vsock_probe() is executing on another CPU? > I have the same doubt. What do you think to take the 'the_virtio_vsock_mutex' in the...

...hould refactor the functions that can be called also from the vsock > > > core, in order to remove "struct net_device *dev" parameter. > > > Maybe creating some wrappers for the network stack. > > > > > > Otherwise I should create a fake net_device for vsock_core. > > > > > > What do you suggest? > > > > Neither. > > > > I think what Jason was saying all along is this: > > > > virtio net doesn't actually lose packets, at least most > > of the time. And it actually most of the time > &gt...

...> @@ -702,28 +702,27 @@ static int __init virtio_vsock_init(void) > > > > if (!virtio_vsock_workqueue) > > > > return -ENOMEM; > > > > > > > > - ret = register_virtio_driver(&virtio_vsock_driver); > > > > + ret = vsock_core_init(&virtio_transport.transport); > > > > > > Have you checked that all transport callbacks are safe even if another > > > CPU calls them while virtio_vsock_probe() is executing on another CPU? > > > > > > > I have the same doubt. > > >...

...o_vsock_init(void) > > > > > > if (!virtio_vsock_workqueue) > > > > > > return -ENOMEM; > > > > > > > > > > > > - ret = register_virtio_driver(&virtio_vsock_driver); > > > > > > + ret = vsock_core_init(&virtio_transport.transport); > > > > > > > > > > Have you checked that all transport callbacks are safe even if another > > > > > CPU calls them while virtio_vsock_probe() is executing on another CPU? > > > > > > > > &g...

...es, that should work. > > So, I should refactor the functions that can be called also from the vsock > core, in order to remove "struct net_device *dev" parameter. > Maybe creating some wrappers for the network stack. > > Otherwise I should create a fake net_device for vsock_core. > > What do you suggest? Neither. I think what Jason was saying all along is this: virtio net doesn't actually lose packets, at least most of the time. And it actually most of the time passes all packets to host. So it's possible to use a virtio net device (possibly with a featu...

On Thu, Jul 11, 2019 at 03:52:21PM -0400, Michael S. Tsirkin wrote: > On Thu, Jul 11, 2019 at 01:41:34PM +0200, Stefano Garzarella wrote: > > On Thu, Jul 11, 2019 at 03:37:00PM +0800, Jason Wang wrote: > > > > > > On 2019/7/10 ??11:37, Stefano Garzarella wrote: > > > > Hi, > > > > as Jason suggested some months ago, I looked better at the

On Thu, Jul 11, 2019 at 03:52:21PM -0400, Michael S. Tsirkin wrote: > On Thu, Jul 11, 2019 at 01:41:34PM +0200, Stefano Garzarella wrote: > > On Thu, Jul 11, 2019 at 03:37:00PM +0800, Jason Wang wrote: > > > > > > On 2019/7/10 ??11:37, Stefano Garzarella wrote: > > > > Hi, > > > > as Jason suggested some months ago, I looked better at the