search for: virtio_f_iommu

...at is limited > to your secure memory range (if you really need it to be runtime > enabled only after a device reset that rescans) and use the normal > dma mapping code to bounce buffer. Who would set this bit ? qemu ? Under what circumstances ? What would be the effect of this bit while VIRTIO_F_IOMMU is NOT set, ie, what would qemu do and what would Linux do ? I'm not sure I fully understand your idea. I'm trying to understand because the limitation is not a device side limitation, it's not a qemu limitation, it's actually more of a VM limitation. It has most of its memory page...

...at is limited > to your secure memory range (if you really need it to be runtime > enabled only after a device reset that rescans) and use the normal > dma mapping code to bounce buffer. Who would set this bit ? qemu ? Under what circumstances ? What would be the effect of this bit while VIRTIO_F_IOMMU is NOT set, ie, what would qemu do and what would Linux do ? I'm not sure I fully understand your idea. I'm trying to understand because the limitation is not a device side limitation, it's not a qemu limitation, it's actually more of a VM limitation. It has most of its memory page...

...e, Hyperv or something so secret that you'd have to shoot me if you had to tell me. The guest might be Linux, FreeBSD, AIX, OS400 or a Hipster project of the day in Rust. As long as we properly specify the interface it simplify does not matter. > What would be the effect of this bit while VIRTIO_F_IOMMU is NOT set, > ie, what would qemu do and what would Linux do ? I'm not sure I fully > understand your idea. In a perfect would we'd just reuse VIRTIO_F_IOMMU and clarify the description which currently is rather vague but basically captures the use case. Currently is is: VIRTIO_F_I...

...s interface. It does NOT change. That information is not part of the interface. It's the VM itself that is stashing away its memory in a secret place, and thus needs to do bounce buffering. There is no change to the virtio interface per-se. > > What would be the effect of this bit while VIRTIO_F_IOMMU is NOT set, > > ie, what would qemu do and what would Linux do ? I'm not sure I fully > > understand your idea. > > In a perfect would we'd just reuse VIRTIO_F_IOMMU and clarify the > description which currently is rather vague but basically captures > the use case....

...s interface. It does NOT change. That information is not part of the interface. It's the VM itself that is stashing away its memory in a secret place, and thus needs to do bounce buffering. There is no change to the virtio interface per-se. > > What would be the effect of this bit while VIRTIO_F_IOMMU is NOT set, > > ie, what would qemu do and what would Linux do ? I'm not sure I fully > > understand your idea. > > In a perfect would we'd just reuse VIRTIO_F_IOMMU and clarify the > description which currently is rather vague but basically captures > the use case....

On Sat, 2018-08-04 at 01:21 -0700, Christoph Hellwig wrote: > No matter if you like it or not (I don't!) virtio is defined to bypass > dma translations, it is very clearly stated in the spec. It has some > ill-defined bits to bypass it, so if you want the dma mapping API > to be used you'll have to set that bit (in its original form, a refined > form, or an entirely newly

On Sat, 2018-08-04 at 01:21 -0700, Christoph Hellwig wrote: > No matter if you like it or not (I don't!) virtio is defined to bypass > dma translations, it is very clearly stated in the spec. It has some > ill-defined bits to bypass it, so if you want the dma mapping API > to be used you'll have to set that bit (in its original form, a refined > form, or an entirely newly