search for: priorietary

...ust rely on Linux virtio "knowing" that it happens. It's a bit yucky but that's now history... Essentially pseries "architecturally" does not have the concept of not having an iommu in the way and qemu violates that architecture today. (Remember it comes from pHyp, our priorietary HV, which we are somewhat mimmicing here). So if we always set VIRTIO_F_IOMMU_PLATFORM, it *will* force all virtio through that iommu and performance will suffer (esp vhost I suspect), especially since adding/removing translations in the iommu is a hypercall. Now, we do have HV APIs to create a s...

...ust rely on Linux virtio "knowing" that it happens. It's a bit yucky but that's now history... Essentially pseries "architecturally" does not have the concept of not having an iommu in the way and qemu violates that architecture today. (Remember it comes from pHyp, our priorietary HV, which we are somewhat mimmicing here). So if we always set VIRTIO_F_IOMMU_PLATFORM, it *will* force all virtio through that iommu and performance will suffer (esp vhost I suspect), especially since adding/removing translations in the iommu is a hypercall. Now, we do have HV APIs to create a s...

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 solution or should i patch asterisk so that it ignores the trailing multipart content of the INVITE request ? (for the record, the e...

...... That is ugly as hell, but it is how virtio works everywhere, so nothing special so far. > Essentially pseries "architecturally" does not have the concept of not > having an iommu in the way and qemu violates that architecture today. > > (Remember it comes from pHyp, our priorietary HV, which we are somewhat > mimmicing here). It shouldnt be too hard to have a dt property that communicates this, should it? > So if we always set VIRTIO_F_IOMMU_PLATFORM, it *will* force all virtio > through that iommu and performance will suffer (esp vhost I suspect), > especially...

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

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

...it is how virtio works everywhere, so nothing > special so far. Yup. > > Essentially pseries "architecturally" does not have the concept of not > > having an iommu in the way and qemu violates that architecture today. > > > > (Remember it comes from pHyp, our priorietary HV, which we are somewhat > > mimmicing here). > > It shouldnt be too hard to have a dt property that communicates this, > should it? We could invent something I suppose. The additional problem then (yeah I know ... what a mess) is that qemu doesn't create the DT for PCI device...

...it is how virtio works everywhere, so nothing > special so far. Yup. > > Essentially pseries "architecturally" does not have the concept of not > > having an iommu in the way and qemu violates that architecture today. > > > > (Remember it comes from pHyp, our priorietary HV, which we are somewhat > > mimmicing here). > > It shouldnt be too hard to have a dt property that communicates this, > should it? We could invent something I suppose. The additional problem then (yeah I know ... what a mess) is that qemu doesn't create the DT for PCI device...