similar to: [RFC V2] virtio: Add platform specific DMA API translation for virito devices

On Wed, 2018-05-23 at 21:50 +0300, Michael S. Tsirkin wrote: > I re-read that discussion and I'm still unclear on the > original question, since I got several apparently > conflicting answers. > > I asked: > > Why isn't setting VIRTIO_F_IOMMU_PLATFORM on the > hypervisor side sufficient? I thought I had replied to this... There are a couple of reasons: -

On Wed, 2018-05-23 at 21:50 +0300, Michael S. Tsirkin wrote: > I re-read that discussion and I'm still unclear on the > original question, since I got several apparently > conflicting answers. > > I asked: > > Why isn't setting VIRTIO_F_IOMMU_PLATFORM on the > hypervisor side sufficient? I thought I had replied to this... There are a couple of reasons: -

On Mon, 2018-06-04 at 15:43 +0300, Michael S. Tsirkin wrote: > On Thu, May 24, 2018 at 08:27:04AM +1000, Benjamin Herrenschmidt wrote: > > On Wed, 2018-05-23 at 21:50 +0300, Michael S. Tsirkin wrote: > > > > > I re-read that discussion and I'm still unclear on the > > > original question, since I got several apparently > > > conflicting answers. >

On Mon, 2018-06-04 at 15:43 +0300, Michael S. Tsirkin wrote: > On Thu, May 24, 2018 at 08:27:04AM +1000, Benjamin Herrenschmidt wrote: > > On Wed, 2018-05-23 at 21:50 +0300, Michael S. Tsirkin wrote: > > > > > I re-read that discussion and I'm still unclear on the > > > original question, since I got several apparently > > > conflicting answers. >

subj: s/virito/virtio/ On Tue, May 22, 2018 at 12:03:17PM +0530, Anshuman Khandual wrote: > This adds a hook which a platform can define in order to allow it to > force the use of the DMA API for all virtio devices even if they don't > have the VIRTIO_F_IOMMU_PLATFORM flag set. We want to use this to do > bounce-buffering of data on the new secure pSeries platform, currently >

On Fri, Jul 20, 2018 at 09:29:41AM +0530, Anshuman Khandual wrote: >Subject: Re: [RFC 4/4] virtio: Add platform specific DMA API translation for > virito devices s/virito/virtio/ > This adds a hook which a platform can define in order to allow it to > override virtio device's DMA OPS irrespective of whether it has the > flag VIRTIO_F_IOMMU_PLATFORM set or not. We want to use

On Fri, Jul 20, 2018 at 09:29:41AM +0530, Anshuman Khandual wrote: >Subject: Re: [RFC 4/4] virtio: Add platform specific DMA API translation for > virito devices s/virito/virtio/ > This adds a hook which a platform can define in order to allow it to > override virtio device's DMA OPS irrespective of whether it has the > flag VIRTIO_F_IOMMU_PLATFORM set or not. We want to use

On Thu, May 24, 2018 at 08:27:04AM +1000, Benjamin Herrenschmidt wrote: > On Wed, 2018-05-23 at 21:50 +0300, Michael S. Tsirkin wrote: > > > I re-read that discussion and I'm still unclear on the > > original question, since I got several apparently > > conflicting answers. > > > > I asked: > > > > Why isn't setting

On Thu, May 24, 2018 at 08:27:04AM +1000, Benjamin Herrenschmidt wrote: > On Wed, 2018-05-23 at 21:50 +0300, Michael S. Tsirkin wrote: > > > I re-read that discussion and I'm still unclear on the > > original question, since I got several apparently > > conflicting answers. > > > > I asked: > > > > Why isn't setting

On Mon, Jun 04, 2018 at 11:11:52PM +1000, Benjamin Herrenschmidt wrote: > On Mon, 2018-06-04 at 15:43 +0300, Michael S. Tsirkin wrote: > > On Thu, May 24, 2018 at 08:27:04AM +1000, Benjamin Herrenschmidt wrote: > > > On Wed, 2018-05-23 at 21:50 +0300, Michael S. Tsirkin wrote: > > > > > > > I re-read that discussion and I'm still unclear on the > >

There are certian platforms which would like to use SWIOTLB based DMA API for bouncing purpose without actually requiring an IOMMU back end. But the virtio core does not allow such mechanism. Right now DMA MAP API is only selected for devices which have an IOMMU and then the QEMU/host back end will process all incoming SG buffer addresses as IOVA instead of simple GPA which is the case for simple

There are certian platforms which would like to use SWIOTLB based DMA API for bouncing purpose without actually requiring an IOMMU back end. But the virtio core does not allow such mechanism. Right now DMA MAP API is only selected for devices which have an IOMMU and then the QEMU/host back end will process all incoming SG buffer addresses as IOVA instead of simple GPA which is the case for simple

On Fri, 2018-05-25 at 20:45 +0300, Michael S. Tsirkin wrote: > On Thu, May 24, 2018 at 08:27:04AM +1000, Benjamin Herrenschmidt wrote: > > On Wed, 2018-05-23 at 21:50 +0300, Michael S. Tsirkin wrote: > > > > > I re-read that discussion and I'm still unclear on the > > > original question, since I got several apparently > > > conflicting answers. >

On Fri, 2018-05-25 at 20:45 +0300, Michael S. Tsirkin wrote: > On Thu, May 24, 2018 at 08:27:04AM +1000, Benjamin Herrenschmidt wrote: > > On Wed, 2018-05-23 at 21:50 +0300, Michael S. Tsirkin wrote: > > > > > I re-read that discussion and I'm still unclear on the > > > original question, since I got several apparently > > > conflicting answers. >

On Mon, 2018-06-04 at 19:21 +0300, Michael S. Tsirkin wrote: > > > > > - First qemu doesn't know that the guest will switch to "secure mode" > > > > in advance. There is no difference between a normal and a secure > > > > partition until the partition does the magic UV call to "enter secure > > > > mode" and qemu

This patch series is the follow up on the discussions we had before about the RFC titled [RFC,V2] virtio: Add platform specific DMA API translation for virito devices (https://patchwork.kernel.org/patch/10417371/). There were suggestions about doing away with two different paths of transactions with the host/QEMU, first being the direct GPA and the other being the DMA API based translations.

This patch series is the follow up on the discussions we had before about the RFC titled [RFC,V2] virtio: Add platform specific DMA API translation for virito devices (https://patchwork.kernel.org/patch/10417371/). There were suggestions about doing away with two different paths of transactions with the host/QEMU, first being the direct GPA and the other being the DMA API based translations.

This adds a hook which a platform can define in order to allow it to override virtio device's DMA OPS irrespective of whether it has the flag VIRTIO_F_IOMMU_PLATFORM set or not. We want to use this to do bounce-buffering of data on the new secure pSeries platform, currently under development, where a KVM host cannot access all of the memory space of a secure KVM guest. The host can only

On 05/24/2018 12:51 PM, Ram Pai wrote: > On Wed, May 23, 2018 at 09:50:02PM +0300, Michael S. Tsirkin wrote: >> subj: s/virito/virtio/ >> > ..snip.. >>> machine_subsys_initcall_sync(pseries, tce_iommu_bus_notifier_init); >>> + >>> +bool platform_forces_virtio_dma(struct virtio_device *vdev) >>> +{ >>> + /* >>> + * On

On 07/20/2018 06:45 PM, Michael S. Tsirkin wrote: > On Fri, Jul 20, 2018 at 09:29:41AM +0530, Anshuman Khandual wrote: >> Subject: Re: [RFC 4/4] virtio: Add platform specific DMA API translation for >> virito devices > > s/virito/virtio/ Oops, will fix it. Thanks for pointing out. > >> This adds a hook which a platform can define in order to allow it to >>