search for: arch_virtio_wants_dma_op

..."poke" something into them. It also means qemu will need some other internal nasty flag that says "set that bit but don't do iommu". It's nicer if we have a way in the guest virtio driver to do something along the lines of if ((flags & VIRTIO_F_IOMMU_PLATFORM) || arch_virtio_wants_dma_ops()) Which would have the same effect and means the issue is entirely contained in the guest. Cheers, Ben.

..."poke" something into them. It also means qemu will need some other internal nasty flag that says "set that bit but don't do iommu". It's nicer if we have a way in the guest virtio driver to do something along the lines of if ((flags & VIRTIO_F_IOMMU_PLATFORM) || arch_virtio_wants_dma_ops()) Which would have the same effect and means the issue is entirely contained in the guest. Cheers, Ben.

...ct with vhost. So the situation isn't that great.... On the other hand, I think the other approach works for us: > > It's nicer if we have a way in the guest virtio driver to do something > > along the lines of > > > > if ((flags & VIRTIO_F_IOMMU_PLATFORM) || arch_virtio_wants_dma_ops()) > > > > Which would have the same effect and means the issue is entirely > > contained in the guest. > > It would not be the same effect. The problem with that is that you must > now assumes that your qemu knows that for example you might be passing > a dma offs...

...ct with vhost. So the situation isn't that great.... On the other hand, I think the other approach works for us: > > It's nicer if we have a way in the guest virtio driver to do something > > along the lines of > > > > if ((flags & VIRTIO_F_IOMMU_PLATFORM) || arch_virtio_wants_dma_ops()) > > > > Which would have the same effect and means the issue is entirely > > contained in the guest. > > It would not be the same effect. The problem with that is that you must > now assumes that your qemu knows that for example you might be passing > a dma offs...

...the topic, see below > > > It would not be the same effect. The problem with that is that you must > > > now assumes that your qemu knows that for example you might be passing > > > a dma offset if the bus otherwise requires it. > > > > I would assume that arch_virtio_wants_dma_ops() only returns true when > > no such offsets are involved, at least in our case that would be what > > happens. > > That would work, but we're really piling hac?s ontop of hacks here. Sort-of :-) At least none of what we are discussing now involves touching the dma_ops them...

...the topic, see below > > > It would not be the same effect. The problem with that is that you must > > > now assumes that your qemu knows that for example you might be passing > > > a dma offset if the bus otherwise requires it. > > > > I would assume that arch_virtio_wants_dma_ops() only returns true when > > no such offsets are involved, at least in our case that would be what > > happens. > > That would work, but we're really piling hac?s ontop of hacks here. Sort-of :-) At least none of what we are discussing now involves touching the dma_ops them...

...on the qemu side of he processing, and with the new direct calls for the direct dma ops performance in the guest won't change either. > It's nicer if we have a way in the guest virtio driver to do something > along the lines of > > if ((flags & VIRTIO_F_IOMMU_PLATFORM) || arch_virtio_wants_dma_ops()) > > Which would have the same effect and means the issue is entirely > contained in the guest. It would not be the same effect. The problem with that is that you must now assumes that your qemu knows that for example you might be passing a dma offset if the bus otherwise requires it...

On Wed, Aug 08, 2018 at 11:18:13PM +1000, Benjamin Herrenschmidt wrote: > Sure, but all of this is just the configuration of the iommu. But I > think we agree here, and your point remains valid, indeed my proposed > hack: > > > if ((flags & VIRTIO_F_IOMMU_PLATFORM) || arch_virtio_wants_dma_ops()) > > Will only work if the IOMMU and non-IOMMU path are completely equivalent. > > We can provide that guarantee for our secure VM case, but not generally so if > we were to go down the route of a quirk in virtio, it might be better to > make it painfully obvious that it'...

...his particular bus we skip the actualy iommu. > > It would not be the same effect. The problem with that is that you must > > now assumes that your qemu knows that for example you might be passing > > a dma offset if the bus otherwise requires it. > > I would assume that arch_virtio_wants_dma_ops() only returns true when > no such offsets are involved, at least in our case that would be what > happens. That would work, but we're really piling hac?s ontop of hacks here. > > Or in other words: > > you potentially break the contract between qemu and the guest of alway...

On Mon, 2018-08-06 at 23:21 -0700, Christoph Hellwig wrote: > On Tue, Aug 07, 2018 at 05:52:12AM +1000, Benjamin Herrenschmidt wrote: > > > It is your job to write a coherent interface specification that does > > > not depend on the used components. The hypervisor might be PAPR, > > > Linux + qemu, VMware, Hyperv or something so secret that you'd have > >

On Mon, 2018-08-06 at 23:21 -0700, Christoph Hellwig wrote: > On Tue, Aug 07, 2018 at 05:52:12AM +1000, Benjamin Herrenschmidt wrote: > > > It is your job to write a coherent interface specification that does > > > not depend on the used components. The hypervisor might be PAPR, > > > Linux + qemu, VMware, Hyperv or something so secret that you'd have > >

...11:18:13PM +1000, Benjamin Herrenschmidt wrote: > > Sure, but all of this is just the configuration of the iommu. But I > > think we agree here, and your point remains valid, indeed my proposed > > hack: > > > > > if ((flags & VIRTIO_F_IOMMU_PLATFORM) || arch_virtio_wants_dma_ops()) > > > > Will only work if the IOMMU and non-IOMMU path are completely equivalent. > > > > We can provide that guarantee for our secure VM case, but not generally so if > > we were to go down the route of a quirk in virtio, it might be better to > > make it...