search for: bypassed

Thu, Apr 05, 2018 at 11:08:21PM CEST, sridhar.samudrala at intel.com wrote: >This 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 driver can use

This 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 driver can use this module by registering a set of ops and each instance of the device when it is probed.

On 18.4.2013 ?. 22:24 ?., Arnaud Quette wrote: > > 2013/4/18 Pladi Computers Ltd. <pladi at lovechnet.com > <mailto:pladi at lovechnet.com>> > > 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

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

The main motivation for this patch is to enable cloud service providers to provide an accelerated datapath to virtio-net enabled VMs in a transparent manner with no/minimal guest userspace changes. This also enables hypervisor controlled live 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

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

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

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

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

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

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

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

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

----- Original Message ----- > From: "Joshua Colp" <jcolp at digium.com> > To: "Asterisk Users Mailing List - Non-Commercial Discussion" <asterisk-users at lists.digium.com> > Sent: Tuesday, May 12, 2015 5:42:57 PM > Subject: Re: [asterisk-users] "Retransmission Timeout" results in dropped calls after 32 seconds > > Andrew Martin wrote:

On Mon, 2015-11-09 at 18:18 -0800, Andy Lutomirski wrote: > > /* Qumranet donated their vendor ID for devices 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

On Mon, 2015-11-09 at 18:18 -0800, Andy Lutomirski wrote: > > /* Qumranet donated their vendor ID for devices 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

...ntiating MSI bypass from > normal reserved range? Is there other example where guest > may use such info to do special thing? The presence of an MSI bypass regions allows the driver and the DMA layer (in Linux iommu_dma_map_msi_msg) to know whether it needs to create a mapping or if it's bypassed. When writing the entry into the MSI-X table, if the address in the MSI vector already corresponds to an MSI bypass region, then there is no need to create a mapping. Making the bypass MSI region a normal RESV range hides that information. Another way of choosing would be with #ifdef CONFIG_ARM64,...

...ntiating MSI bypass from > normal reserved range? Is there other example where guest > may use such info to do special thing? The presence of an MSI bypass regions allows the driver and the DMA layer (in Linux iommu_dma_map_msi_msg) to know whether it needs to create a mapping or if it's bypassed. When writing the entry into the MSI-X table, if the address in the MSI vector already corresponds to an MSI bypass region, then there is no need to create a mapping. Making the bypass MSI region a normal RESV range hides that information. Another way of choosing would be with #ifdef CONFIG_ARM64,...

On 2/21/2018 5:59 PM, Siwei Liu wrote: > On Wed, Feb 21, 2018 at 4:17 PM, Alexander Duyck > <alexander.duyck at gmail.com> wrote: >> 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

On 2/21/2018 5:59 PM, Siwei Liu wrote: > On Wed, Feb 21, 2018 at 4:17 PM, Alexander Duyck > <alexander.duyck at gmail.com> wrote: >> 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