search for: bypass

...ent handling code is based on the existing netvsc implementation. A >paravirtual driver can use this module by registering a set of ops and >each instance of the device when it is probed. > >Signed-off-by: Sridhar Samudrala <sridhar.samudrala at intel.com> >--- > include/net/bypass.h | 80 ++++++++++ > net/Kconfig | 18 +++ > net/core/Makefile | 1 + > net/core/bypass.c | 406 +++++++++++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 505 insertions(+) > create mode 100644 include/net/bypass.h > create mode 100644 net/core/bypass.c...

...ath. The notifier and event handling code is based on the existing netvsc implementation. A paravirtual driver can use this module by registering a set of ops and each instance of the device when it is probed. Signed-off-by: Sridhar Samudrala <sridhar.samudrala at intel.com> --- include/net/bypass.h | 80 ++++++++++ net/Kconfig | 18 +++ net/core/Makefile | 1 + net/core/bypass.c | 406 +++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 505 insertions(+) create mode 100644 include/net/bypass.h create mode 100644 net/core/bypass.c diff --git a/include/n...

...--- next part -------------- ./mge-utalk -DDD -a ups0 Network UPS Tools - MGE UPS SYSTEMS/U-Talk driver 0.93 (2.6.5) 0.000000 debug level is '3' 2.105848 Got model name: NAK 3.193505 Syst Stat >NAK< 3.741509 Batt Stat >NAK< 4.280759 Load Stat > < 4.828750 Bypass Stat >ACK< 5.376322 Syst Stat >NAK< 5.924311 Batt Stat >NAK< 6.464392 Load Stat > < 7.012386 Bypass Stat >ACK< 7.559960 Syst Stat >NAK< 8.107945 Batt Stat >NAK< 8.647195 Load Stat > < 9.194774 Bypass Stat >ACK< 9.74234...

UPS: http://www.eaton.com/Eaton/ESeriesUPS/DXUPS/index.htm?wtredirect=www.eaton.com/DXUPS I have the same problem on two different computers. The first one is running Ubuntu 12.10 i386 , the second one is running Debian 6.0 x64. Both of them are updated. I tried using different serial cable but the result is the same. The connection to the ups using Windows 7 and Winpower is working fine on

...e migration to be supported with VMs that have direct attached SR-IOV VF devices. Patch 1 introduces a new feature bit VIRTIO_NET_F_BACKUP that can be used by hypervisor to indicate that virtio_net interface should act as a backup for another device with the same MAC address. Patch 2 introduces a bypass module that provides a generic interface for paravirtual drivers to listen for netdev register/unregister/link change events from pci ethernet devices with the same MAC and takeover their datapath. The notifier and event handling code is based on the existing netvsc implementation. A paravirtual d...

On Wed, Apr 27, 2016 at 04:37:04PM +0300, Michael S. Tsirkin wrote: > One correction: it's a feature of the device in the system. > There could be a mix of devices bypassing and not > bypassing the IOMMU. No, it really is not. A device can't chose to bypass the IOMMU. But the IOMMU can chose to let the device bypass. So any fix here belongs into the platform/iommu code too and not into some driver. > Sounds good. And a way to detect appropriate devices c...

On Wed, Apr 27, 2016 at 04:37:04PM +0300, Michael S. Tsirkin wrote: > One correction: it's a feature of the device in the system. > There could be a mix of devices bypassing and not > bypassing the IOMMU. No, it really is not. A device can't chose to bypass the IOMMU. But the IOMMU can chose to let the device bypass. So any fix here belongs into the platform/iommu code too and not into some driver. > Sounds good. And a way to detect appropriate devices c...

So ... I've finally tried to sort that out for powerpc and I can't find a way to make that work that isn't a complete pile of stinking shit. I'm very tempted to go back to my original idea: virtio itself should indicate it's "bypassing ability" via the virtio config space or some other bit (like the ProgIf of the PCI header etc...). I don't see how I can make it work otherwise. The problem with the statement "it's a platform matter" is that: ? - It's not entirely correct. It's actually a featu...

So ... I've finally tried to sort that out for powerpc and I can't find a way to make that work that isn't a complete pile of stinking shit. I'm very tempted to go back to my original idea: virtio itself should indicate it's "bypassing ability" via the virtio config space or some other bit (like the ProgIf of the PCI header etc...). I don't see how I can make it work otherwise. The problem with the statement "it's a platform matter" is that: ? - It's not entirely correct. It's actually a featu...

On Mon, 2015-11-09 at 16:46 -0800, Andy Lutomirski wrote: > The problem here is that in some of the problematic cases the virtio > driver may not even be loaded.? If someone runs an L1 guest with an > IOMMU-bypassing virtio device and assigns it to L2 using vfio, then > *boom* L1 crashes.? (Same if, say, DPDK gets used, I think.) > > > > > The only way out of this while keeping the "platform" stuff would be to > > also bump some kind of version in the virtio config (or PCI...

On Mon, 2015-11-09 at 16:46 -0800, Andy Lutomirski wrote: > The problem here is that in some of the problematic cases the virtio > driver may not even be loaded.? If someone runs an L1 guest with an > IOMMU-bypassing virtio device and assigns it to L2 using vfio, then > *boom* L1 crashes.? (Same if, say, DPDK gets used, I think.) > > > > > The only way out of this while keeping the "platform" stuff would be to > > also bump some kind of version in the virtio config (or PCI...

On Mon, 2015-11-09 at 21:35 -0800, Andy Lutomirski wrote: > > We could do it the other way around: on powerpc, if a PCI device is in > that range and doesn't have the "bypass" property at all, then it's > assumed to bypass the IOMMU.??This means that everything that > currently works continues working.??If someone builds a physical > virtio device or uses another system in PCIe target mode speaking > virtio, then it won't work until they upgrade...

On Mon, 2015-11-09 at 21:35 -0800, Andy Lutomirski wrote: > > We could do it the other way around: on powerpc, if a PCI device is in > that range and doesn't have the "bypass" property at all, then it's > assumed to bypass the IOMMU.??This means that everything that > currently works continues working.??If someone builds a physical > virtio device or uses another system in PCIe target mode speaking > virtio, then it won't work until they upgrade...

...SIP packets: INVITE (102) - initial call connecting RINGING (102) - initial call connecting RINGING (102) - initial call connecting OK (102) - initial call connecting ACK (102) - initial call connecting OK (102) - initial call connecting (seems like a duplicate OK) INVITE (103) - re-INVITE to go to bypass mode ACK (102) - initial call connecting (seems like a duplicate ACK) INVITE (103) - re-INVITE to go to bypass mode (retry #1) INVITE (103) - re-INVITE to go to bypass mode (retry #2) INVITE (103) - re-INVITE to go to bypass mode (retry #3) INVITE (103) - re-INVITE to go to bypass mode (retry #4) I...

...ices 0x1000 thru 0x10FF. > */ > static const struct pci_device_id virtio_pci_id_table[] = { > ??????? { PCI_DEVICE(0x1af4, PCI_ANY_ID) }, > ??????? { 0 } > }; > > Can we match on that range? We can, but the problem remains, how do we differenciate an existing device that does bypass vs. a newer one that needs the IOMMU and thus doesn't have the new "bypass" property in the device-tree. Cheers, Ben.

...ices 0x1000 thru 0x10FF. > */ > static const struct pci_device_id virtio_pci_id_table[] = { > ??????? { PCI_DEVICE(0x1af4, PCI_ANY_ID) }, > ??????? { 0 } > }; > > Can we match on that range? We can, but the problem remains, how do we differenciate an existing device that does bypass vs. a newer one that needs the IOMMU and thus doesn't have the new "bypass" property in the device-tree. Cheers, Ben.

Hi Kevin, Thanks for the comments On 19/03/18 10:03, Tian, Kevin wrote: > BYPASS feature bit is not covered in "2.3.1/2.3.2/2.3.3"". Is it > intended? In my opinion BYPASS is a bit different from the other features: while the others are needed for correctness, this one is optional and even if the guest supports BYPASS, it should be allowed not to accept it....

Hi Kevin, Thanks for the comments On 19/03/18 10:03, Tian, Kevin wrote: > BYPASS feature bit is not covered in "2.3.1/2.3.2/2.3.3"". Is it > intended? In my opinion BYPASS is a bit different from the other features: while the others are needed for correctness, this one is optional and even if the guest supports BYPASS, it should be allowed not to accept it....

...on. However, it creates some issues we'll get into in a moment. >>>>>> It extends virtio_net to use alternate datapath when available and >>>>>> registered. When BACKUP feature is enabled, virtio_net driver creates >>>>>> an additional 'bypass' netdev that acts as a master device and controls >>>>>> 2 slave devices. The original virtio_net netdev is registered as >>>>>> 'backup' netdev and a passthru/vf device with the same MAC gets >>>>>> registered as 'active' n...

...on. However, it creates some issues we'll get into in a moment. >>>>>> It extends virtio_net to use alternate datapath when available and >>>>>> registered. When BACKUP feature is enabled, virtio_net driver creates >>>>>> an additional 'bypass' netdev that acts as a master device and controls >>>>>> 2 slave devices. The original virtio_net netdev is registered as >>>>>> 'backup' netdev and a passthru/vf device with the same MAC gets >>>>>> registered as 'active' n...