search for: virtio_bypass

On Sun, Apr 01, 2018 at 05:13:10AM -0400, Si-Wei Liu wrote: > diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h > index aa40664..0827b7e 100644 > --- a/include/uapi/linux/virtio_net.h > +++ b/include/uapi/linux/virtio_net.h > @@ -80,6 +80,8 @@ struct virtio_net_config { > __u16 max_virtqueue_pairs; > /* Default maximum transmit unit advice */

...of how to allow a cloud provider to >>upgrade their customer to SR-IOV support and live migration without >>requiring them to reconfigure their guest. So the general idea with >>our patch is to take a VM that is running with virtio_net only and >>allow it to instead spawn a virtio_bypass master using the same netdev >>name as the original virtio, and then have the virtio_net and VF come >>up and be enslaved by the bypass interface. Doing it this way we can >>allow for multi-vendor SR-IOV live migration support using a guest >>that was originally configured f...

...of how to allow a cloud provider to >>upgrade their customer to SR-IOV support and live migration without >>requiring them to reconfigure their guest. So the general idea with >>our patch is to take a VM that is running with virtio_net only and >>allow it to instead spawn a virtio_bypass master using the same netdev >>name as the original virtio, and then have the virtio_net and VF come >>up and be enslaved by the bypass interface. Doing it this way we can >>allow for multi-vendor SR-IOV live migration support using a guest >>that was originally configured f...

Wed, Apr 04, 2018 at 03:04:26AM CEST, dsahern at gmail.com wrote: >On 4/3/18 9:42 AM, Jiri Pirko wrote: >>> >>> There are other use cases that want to hide a device from userspace. I >> >> What usecases do you have in mind? > >As mentioned in a previous response some kernel drivers create control >netdevs. Just as in this case users should not be mucking

...users to list all devices -- even ones What kind of API you would like to query for hidden devices? rtnetlink? a private socket API? or something else? For our case, the sysfs interface is what we need and is sufficient, since udev is the main target we'd like to support to make the naming of virtio_bypass consistent and compatible. > hidden by default. > > https://github.com/dsahern/linux/commit/48a80a00eac284e58bae04af10a5a932dd7aee00 > > https://github.com/dsahern/iproute2/commit/7563f5b26f5539960e99066e34a995d22ea908ed > > Also, why are you suggesting that the device should...

...tempting to resolve is the issue of how to allow a cloud provider to upgrade their customer to SR-IOV support and live migration without requiring them to reconfigure their guest. So the general idea with our patch is to take a VM that is running with virtio_net only and allow it to instead spawn a virtio_bypass master using the same netdev name as the original virtio, and then have the virtio_net and VF come up and be enslaved by the bypass interface. Doing it this way we can allow for multi-vendor SR-IOV live migration support using a guest that was originally configured for virtio only. The problem wit...

...tempting to resolve is the issue of how to allow a cloud provider to upgrade their customer to SR-IOV support and live migration without requiring them to reconfigure their guest. So the general idea with our patch is to take a VM that is running with virtio_net only and allow it to instead spawn a virtio_bypass master using the same netdev name as the original virtio, and then have the virtio_net and VF come up and be enslaved by the bypass interface. Doing it this way we can allow for multi-vendor SR-IOV live migration support using a guest that was originally configured for virtio only. The problem wit...

...a cloud provider to >>>upgrade their customer to SR-IOV support and live migration without >>>requiring them to reconfigure their guest. So the general idea with >>>our patch is to take a VM that is running with virtio_net only and >>>allow it to instead spawn a virtio_bypass master using the same netdev >>>name as the original virtio, and then have the virtio_net and VF come >>>up and be enslaved by the bypass interface. Doing it this way we can >>>allow for multi-vendor SR-IOV live migration support using a guest >>>that was origina...

...r to >>>>upgrade their customer to SR-IOV support and live migration without >>>>requiring them to reconfigure their guest. So the general idea with >>>>our patch is to take a VM that is running with virtio_net only and >>>>allow it to instead spawn a virtio_bypass master using the same netdev >>>>name as the original virtio, and then have the virtio_net and VF come >>>>up and be enslaved by the bypass interface. Doing it this way we can >>>>allow for multi-vendor SR-IOV live migration support using a guest >>>>...

...r to >>>>upgrade their customer to SR-IOV support and live migration without >>>>requiring them to reconfigure their guest. So the general idea with >>>>our patch is to take a VM that is running with virtio_net only and >>>>allow it to instead spawn a virtio_bypass master using the same netdev >>>>name as the original virtio, and then have the virtio_net and VF come >>>>up and be enslaved by the bypass interface. Doing it this way we can >>>>allow for multi-vendor SR-IOV live migration support using a guest >>>>...

...lve is the issue of how to allow a cloud provider to >upgrade their customer to SR-IOV support and live migration without >requiring them to reconfigure their guest. So the general idea with >our patch is to take a VM that is running with virtio_net only and >allow it to instead spawn a virtio_bypass master using the same netdev >name as the original virtio, and then have the virtio_net and VF come >up and be enslaved by the bypass interface. Doing it this way we can >allow for multi-vendor SR-IOV live migration support using a guest >that was originally configured for virtio only....

...;>>upgrade their customer to SR-IOV support and live migration without >>>>>requiring them to reconfigure their guest. So the general idea with >>>>>our patch is to take a VM that is running with virtio_net only and >>>>>allow it to instead spawn a virtio_bypass master using the same netdev >>>>>name as the original virtio, and then have the virtio_net and VF come >>>>>up and be enslaved by the bypass interface. Doing it this way we can >>>>>allow for multi-vendor SR-IOV live migration support using a guest >...

...rade their customer to SR-IOV support and live migration without >>>>>>requiring them to reconfigure their guest. So the general idea with >>>>>>our patch is to take a VM that is running with virtio_net only and >>>>>>allow it to instead spawn a virtio_bypass master using the same netdev >>>>>>name as the original virtio, and then have the virtio_net and VF come >>>>>>up and be enslaved by the bypass interface. Doing it this way we can >>>>>>allow for multi-vendor SR-IOV live migration support using...

...rade their customer to SR-IOV support and live migration without >>>>>>requiring them to reconfigure their guest. So the general idea with >>>>>>our patch is to take a VM that is running with virtio_net only and >>>>>>allow it to instead spawn a virtio_bypass master using the same netdev >>>>>>name as the original virtio, and then have the virtio_net and VF come >>>>>>up and be enslaved by the bypass interface. Doing it this way we can >>>>>>allow for multi-vendor SR-IOV live migration support using...

...ustomer to SR-IOV support and live migration without >>>>>>>requiring them to reconfigure their guest. So the general idea with >>>>>>>our patch is to take a VM that is running with virtio_net only and >>>>>>>allow it to instead spawn a virtio_bypass master using the same netdev >>>>>>>name as the original virtio, and then have the virtio_net and VF come >>>>>>>up and be enslaved by the bypass interface. Doing it this way we can >>>>>>>allow for multi-vendor SR-IOV live migration su...

On Tue, 20 Feb 2018 21:14:10 +0100, Jiri Pirko wrote: > Yeah, I can see it now :( I guess that the ship has sailed and we are > stuck with this ugly thing forever... > > Could you at least make some common code that is shared in between > netvsc and virtio_net so this is handled in exacly the same way in both? IMHO netvsc is a vendor specific driver which made a mistake on what

On Tue, 20 Feb 2018 21:14:10 +0100, Jiri Pirko wrote: > Yeah, I can see it now :( I guess that the ship has sailed and we are > stuck with this ugly thing forever... > > Could you at least make some common code that is shared in between > netvsc and virtio_net so this is handled in exacly the same way in both? IMHO netvsc is a vendor specific driver which made a mistake on what

...R-IOV support and live migration without >>>>>>>>requiring them to reconfigure their guest. So the general idea with >>>>>>>>our patch is to take a VM that is running with virtio_net only and >>>>>>>>allow it to instead spawn a virtio_bypass master using the same netdev >>>>>>>>name as the original virtio, and then have the virtio_net and VF come >>>>>>>>up and be enslaved by the bypass interface. Doing it this way we can >>>>>>>>allow for multi-vendor SR-IOV live...

...R-IOV support and live migration without >>>>>>>>requiring them to reconfigure their guest. So the general idea with >>>>>>>>our patch is to take a VM that is running with virtio_net only and >>>>>>>>allow it to instead spawn a virtio_bypass master using the same netdev >>>>>>>>name as the original virtio, and then have the virtio_net and VF come >>>>>>>>up and be enslaved by the bypass interface. Doing it this way we can >>>>>>>>allow for multi-vendor SR-IOV live...

On Wed, Feb 21, 2018 at 3:50 PM, Siwei Liu <loseweigh at gmail.com> wrote: > I haven't checked emails for days and did not realize the new revision > had already came out. And thank you for the effort, this revision > really looks to be a step forward towards our use case and is close to > what we wanted to do. A few questions in line. > > On Sat, Feb 17, 2018 at 9:12