search for: unmap_single

...; > The problem is that Linux virtio drivers use virt_to_phys to get the > > guest pseudo-physical addresses to pass to the backend, which doesn't > > work as expected on Xen. > > > > Switching the virtio drivers to the dma APIs (dma_alloc_coherent, > > dma_map/unmap_single and dma_map/unmap_sg) would solve the problem, as > > Xen support in Linux provides an implementation of the dma API which > > takes care of the additional address conversions. However using the dma > > API would increase the complexity of the non-Xen case too. We would also >...

...; > The problem is that Linux virtio drivers use virt_to_phys to get the > > guest pseudo-physical addresses to pass to the backend, which doesn't > > work as expected on Xen. > > > > Switching the virtio drivers to the dma APIs (dma_alloc_coherent, > > dma_map/unmap_single and dma_map/unmap_sg) would solve the problem, as > > Xen support in Linux provides an implementation of the dma API which > > takes care of the additional address conversions. However using the dma > > API would increase the complexity of the non-Xen case too. We would also >...

Hi, I just want to know if somebody use 2.6.31.4 xenified kernel (aka OpenSUSE) in production? We have been testing it on new Nehalem Xeon server for few weeks w/o any problem. But as soon we tried it on production machine - after several production domUs started - hard OS failure. We had to switch back to 2.6.18.8 - xen stock kernel. Peter _______________________________________________

...tual machine with virtio devices (nested virt scenario). The problem is that Linux virtio drivers use virt_to_phys to get the guest pseudo-physical addresses to pass to the backend, which doesn't work as expected on Xen. Switching the virtio drivers to the dma APIs (dma_alloc_coherent, dma_map/unmap_single and dma_map/unmap_sg) would solve the problem, as Xen support in Linux provides an implementation of the dma API which takes care of the additional address conversions. However using the dma API would increase the complexity of the non-Xen case too. We would also need to keep track of the physical...

...tual machine with virtio devices (nested virt scenario). The problem is that Linux virtio drivers use virt_to_phys to get the guest pseudo-physical addresses to pass to the backend, which doesn't work as expected on Xen. Switching the virtio drivers to the dma APIs (dma_alloc_coherent, dma_map/unmap_single and dma_map/unmap_sg) would solve the problem, as Xen support in Linux provides an implementation of the dma API which takes care of the additional address conversions. However using the dma API would increase the complexity of the non-Xen case too. We would also need to keep track of the physical...

...ers use virt_to_phys to get the > >> > guest pseudo-physical addresses to pass to the backend, which doesn't > >> > work as expected on Xen. > >> > > >> > Switching the virtio drivers to the dma APIs (dma_alloc_coherent, > >> > dma_map/unmap_single and dma_map/unmap_sg) would solve the problem, as > >> > Xen support in Linux provides an implementation of the dma API which > >> > takes care of the additional address conversions. However using the dma > >> > API would increase the complexity of the non-Xen ca...

...ers use virt_to_phys to get the > >> > guest pseudo-physical addresses to pass to the backend, which doesn't > >> > work as expected on Xen. > >> > > >> > Switching the virtio drivers to the dma APIs (dma_alloc_coherent, > >> > dma_map/unmap_single and dma_map/unmap_sg) would solve the problem, as > >> > Xen support in Linux provides an implementation of the dma API which > >> > takes care of the additional address conversions. However using the dma > >> > API would increase the complexity of the non-Xen ca...

...ers use virt_to_phys to get the > >> > guest pseudo-physical addresses to pass to the backend, which doesn't > >> > work as expected on Xen. > >> > > >> > Switching the virtio drivers to the dma APIs (dma_alloc_coherent, > >> > dma_map/unmap_single and dma_map/unmap_sg) would solve the problem, as > >> > Xen support in Linux provides an implementation of the dma API which > >> > takes care of the additional address conversions. However using the dma > >> > API would increase the complexity of the non-Xen ca...

...ers use virt_to_phys to get the > >> > guest pseudo-physical addresses to pass to the backend, which doesn't > >> > work as expected on Xen. > >> > > >> > Switching the virtio drivers to the dma APIs (dma_alloc_coherent, > >> > dma_map/unmap_single and dma_map/unmap_sg) would solve the problem, as > >> > Xen support in Linux provides an implementation of the dma API which > >> > takes care of the additional address conversions. However using the dma > >> > API would increase the complexity of the non-Xen ca...

...es (nested virt scenario). > The problem is that Linux virtio drivers use virt_to_phys to get the > guest pseudo-physical addresses to pass to the backend, which doesn't > work as expected on Xen. > > Switching the virtio drivers to the dma APIs (dma_alloc_coherent, > dma_map/unmap_single and dma_map/unmap_sg) would solve the problem, as > Xen support in Linux provides an implementation of the dma API which > takes care of the additional address conversions. However using the dma > API would increase the complexity of the non-Xen case too. We would also > need to keep tr...

...is that Linux virtio drivers use virt_to_phys to get the >> > guest pseudo-physical addresses to pass to the backend, which doesn't >> > work as expected on Xen. >> > >> > Switching the virtio drivers to the dma APIs (dma_alloc_coherent, >> > dma_map/unmap_single and dma_map/unmap_sg) would solve the problem, as >> > Xen support in Linux provides an implementation of the dma API which >> > takes care of the additional address conversions. However using the dma >> > API would increase the complexity of the non-Xen case too. We woul...

Hi all, Here''s a work in progress series whcih does a partial revert of the previous swiotlb changes, and does a partial replacement with Becky Bruce''s series. The most important difference is Becky''s use of phys_addr_t rather than page+offset to represent arbitrary pages. This turns out to be simpler. I didn''t replicate the map_single_page changes, since

...to get the >> >> > guest pseudo-physical addresses to pass to the backend, which doesn't >> >> > work as expected on Xen. >> >> > >> >> > Switching the virtio drivers to the dma APIs (dma_alloc_coherent, >> >> > dma_map/unmap_single and dma_map/unmap_sg) would solve the problem, as >> >> > Xen support in Linux provides an implementation of the dma API which >> >> > takes care of the additional address conversions. However using the dma >> >> > API would increase the complexity of th...

...for the non-Xen case. Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com> --- I realize that this patch is not very nice, but at least it is easy to understand. I welcome any suggestions on how to improve it. I considered introducing regular dma API calls, like dma_map/unmap_single and dma_map/unmap_sg. However they would make the non-Xen code path more complex than it is today. We would also need to keep track of the physical or virtual address in addition to the dma address for each vring_desc to be able to free the memory in detach_buf. --- drivers/virtio/virtio_ring.c...

I am getting the following on my 'new box' for my DNS server: Date: Wed, 20 Feb 2013 13:58:04 -0500 From: To: Subject: [abrt] full crash report User-Agent: Heirloom mailx 12.4 7/29/08 abrt_version: 2.0.8 cmdline: ro root=/dev/mapper/vg_onlo3-root_01 rd_NO_LUKS rd_LVM_LV=vg_onlo3/root_01 LANG=en_US.UTF-8 +rd_NO_MD SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us

Convert the AMD iommu driver to the dma-iommu api. Remove the iova handling and reserve region code from the AMD iommu driver. Change-log: V6: -add more details to the description of patch 001-iommu-amd-Remove-unnecessary-locking-from-AMD-iommu-.patch -rename handle_deferred_device to iommu_dma_deferred_attach -fix double tabs in 0003-iommu-dma-iommu-Handle-deferred-devices.patch V5: -Rebase on

Convert the AMD iommu driver to the dma-iommu api. Remove the iova handling and reserve region code from the AMD iommu driver. Change-log: V4: -Rebase on top of linux-next -Split the removing of the unnecessary locking in the amd iommu driver into a seperate patch -refactor the "iommu/dma-iommu: Handle deferred devices" patch and address comments v3: -rename dma_limit to dma_mask -exit

Convert the AMD iommu driver to the dma-iommu api. Remove the iova handling and reserve region code from the AMD iommu driver. Change-log: V4: -Rebase on top of linux-next -Split the removing of the unnecessary locking in the amd iommu driver into a seperate patch -refactor the "iommu/dma-iommu: Handle deferred devices" patch and address comments v3: -rename dma_limit to dma_mask -exit

Hi, This is third approach (complete this time) for replacing struct dma_attrs with unsigned long. The main patch (2/45) doing the change is split into many subpatches for easier review (3-43). They should be squashed together when applying. *Important:* Patchset is *only* build tested on allyesconfigs: ARM, ARM64, i386, x86_64 and powerpc. Please provide reviewes and tests for other

Hi Ingo, Here''s the chunk of patches to add Xen Dom0 support (it''s probably worth creating a new xen/dom0 topic branch for it). A dom0 Xen domain is basically the same as a normal domU domain, but it has extra privileges to directly access hardware. There are two issues to deal with: - translating to and from the domain''s pseudo-physical addresses and real machine