Displaying 8 results from an estimated 8 matches for "priorietari".
Did you mean:
priorietary
2018 Aug 08
2
[RFC 0/4] Virtio uses DMA API for all devices
On Tue, 2018-08-07 at 23:31 -0700, Christoph Hellwig wrote:
>
> You don't need to set them the time you go secure. You just need to
> set the flag from the beginning on any VM you might want to go secure.
> Or for simplicity just any VM - if the DT/ACPI tables exposed by
> qemu are good enough that will always exclude a iommu and not set a
> DMA offset, so nothing will
2018 Aug 08
2
[RFC 0/4] Virtio uses DMA API for all devices
On Tue, 2018-08-07 at 23:31 -0700, Christoph Hellwig wrote:
>
> You don't need to set them the time you go secure. You just need to
> set the flag from the beginning on any VM you might want to go secure.
> Or for simplicity just any VM - if the DT/ACPI tables exposed by
> qemu are good enough that will always exclude a iommu and not set a
> DMA offset, so nothing will
2006 Apr 21
0
Airspan / Arelnet GW and Asterisk
Hi all
Has anyone seen this kind of messages :
Apr 21 12:04:12 NOTICE[89928]: chan_sip.c:3449 process_sdp: Content
is 'multipart/mixed;boundary=unique-boundary-1', not 'application/sdp'
I get this using a priorietary (Airspan's prime, ex-arelnet) E1
gateway with asterisk. It seems like the SIP protocol they're using
is somehow weird...
Is there a configuration-level
2018 Aug 08
0
[RFC 0/4] Virtio uses DMA API for all devices
On Wed, Aug 08, 2018 at 08:07:49PM +1000, Benjamin Herrenschmidt wrote:
> Qemu virtio bypasses that iommu when the VIRTIO_F_IOMMU_PLATFORM flag
> is not set (default) but there's nothing in the device-tree to tell the
> guest about this since it's a violation of our pseries architecture, so
> we just rely on Linux virtio "knowing" that it happens. It's a bit
>
2018 Aug 07
2
[RFC 0/4] Virtio uses DMA API for all devices
On Tue, 2018-08-07 at 06:55 -0700, Christoph Hellwig wrote:
> On Tue, Aug 07, 2018 at 04:42:44PM +1000, Benjamin Herrenschmidt wrote:
> > Note that I can make it so that the same DMA ops (basically standard
> > swiotlb ops without arch hacks) work for both "direct virtio" and
> > "normal PCI" devices.
> >
> > The trick is simply in the arch to
2018 Aug 07
2
[RFC 0/4] Virtio uses DMA API for all devices
On Tue, 2018-08-07 at 06:55 -0700, Christoph Hellwig wrote:
> On Tue, Aug 07, 2018 at 04:42:44PM +1000, Benjamin Herrenschmidt wrote:
> > Note that I can make it so that the same DMA ops (basically standard
> > swiotlb ops without arch hacks) work for both "direct virtio" and
> > "normal PCI" devices.
> >
> > The trick is simply in the arch to
2018 Aug 08
2
[RFC 0/4] Virtio uses DMA API for all devices
On Wed, 2018-08-08 at 05:30 -0700, Christoph Hellwig wrote:
> On Wed, Aug 08, 2018 at 08:07:49PM +1000, Benjamin Herrenschmidt wrote:
> > Qemu virtio bypasses that iommu when the VIRTIO_F_IOMMU_PLATFORM flag
> > is not set (default) but there's nothing in the device-tree to tell the
> > guest about this since it's a violation of our pseries architecture, so
> >
2018 Aug 08
2
[RFC 0/4] Virtio uses DMA API for all devices
On Wed, 2018-08-08 at 05:30 -0700, Christoph Hellwig wrote:
> On Wed, Aug 08, 2018 at 08:07:49PM +1000, Benjamin Herrenschmidt wrote:
> > Qemu virtio bypasses that iommu when the VIRTIO_F_IOMMU_PLATFORM flag
> > is not set (default) but there's nothing in the device-tree to tell the
> > guest about this since it's a violation of our pseries architecture, so
> >