search for: dma_attr_iommu_bypass

...t; and you don't want the overhead of tweaking IOMMU > > on data path for virtio. Thus iommu=on is out too. > > That's not at all special for virtio or guest VMs. Even with real > hardware, we might want performance from *some* devices, and security > from others. See the DMA_ATTR_IOMMU_BYPASS which is currently being > discussed. Right. So let's wait for that discussion to play out? > But of course the easy answer in *your* case it just to ask the > hypervisor not to put the virtio devices behind an IOMMU at all. Which > we were planning to remain the default behaviour...

...t; and you don't want the overhead of tweaking IOMMU > > on data path for virtio. Thus iommu=on is out too. > > That's not at all special for virtio or guest VMs. Even with real > hardware, we might want performance from *some* devices, and security > from others. See the DMA_ATTR_IOMMU_BYPASS which is currently being > discussed. Right. So let's wait for that discussion to play out? > But of course the easy answer in *your* case it just to ask the > hypervisor not to put the virtio devices behind an IOMMU at all. Which > we were planning to remain the default behaviour...

On Wed, Oct 28, 2015 at 03:51:58PM -0700, Andy Lutomirski wrote: > On Wed, Oct 28, 2015 at 9:12 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > > On Wed, Oct 28, 2015 at 11:32:34PM +0900, David Woodhouse wrote: > >> > I don't have a problem with extending DMA API to address > >> > more usecases. > >> > >> No, this isn't an

On Wed, Oct 28, 2015 at 03:51:58PM -0700, Andy Lutomirski wrote: > On Wed, Oct 28, 2015 at 9:12 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > > On Wed, Oct 28, 2015 at 11:32:34PM +0900, David Woodhouse wrote: > >> > I don't have a problem with extending DMA API to address > >> > more usecases. > >> > >> No, this isn't an

...io and we find ways to identify them. It would be kind of a mix of what you did and what Stefano did. And alternative would be a quirk: make DMA API create 1:1 mappings for virtio devices only. Then teach Xen pv to ignore this quirk. This is what I referred to above. For example, something like DMA_ATTR_IOMMU_BYPASS would do the trick nicely. If there's a chance that's going to be upstream, we could use that. -- MST

...io and we find ways to identify them. It would be kind of a mix of what you did and what Stefano did. And alternative would be a quirk: make DMA API create 1:1 mappings for virtio devices only. Then teach Xen pv to ignore this quirk. This is what I referred to above. For example, something like DMA_ATTR_IOMMU_BYPASS would do the trick nicely. If there's a chance that's going to be upstream, we could use that. -- MST

...ave no choice anyway), > and you don't want the overhead of tweaking IOMMU > on data path for virtio. Thus iommu=on is out too. That's not at all special for virtio or guest VMs. Even with real hardware, we might want performance from *some* devices, and security from others. See the DMA_ATTR_IOMMU_BYPASS which is currently being discussed. But of course the easy answer in *your* case it just to ask the hypervisor not to put the virtio devices behind an IOMMU at all. Which we were planning to remain the default behaviour. In all cases, the DMA API shall do the right thing. -- dwmw2 -----------...

On Mon, Dec 14, 2015 at 02:00:05PM +0000, David Vrabel wrote: > On 07/12/15 16:19, Stefano Stabellini wrote: > > Hi all, > > > > this patch series introduces support for running Linux on top of Xen > > inside a virtual machine with virtio devices (nested virt scenario). > > The problem is that Linux virtio drivers use virt_to_phys to get the > > guest

On Mon, Dec 14, 2015 at 02:00:05PM +0000, David Vrabel wrote: > On 07/12/15 16:19, Stefano Stabellini wrote: > > Hi all, > > > > this patch series introduces support for running Linux on top of Xen > > inside a virtual machine with virtio devices (nested virt scenario). > > The problem is that Linux virtio drivers use virt_to_phys to get the > > guest

On Wed, 2015-11-11 at 07:56 -0800, Andy Lutomirski wrote: > > Can you flesh out this trick? > > On x86 IIUC the IOMMU more-or-less defaults to passthrough. If the > kernel wants, it can switch it to a non-passthrough mode. My patches > cause the virtio driver to do exactly this, except that the host > implementation doesn't actually exist yet, so the patches will

On Wed, 2015-11-11 at 07:56 -0800, Andy Lutomirski wrote: > > Can you flesh out this trick? > > On x86 IIUC the IOMMU more-or-less defaults to passthrough. If the > kernel wants, it can switch it to a non-passthrough mode. My patches > cause the virtio driver to do exactly this, except that the host > implementation doesn't actually exist yet, so the patches will