Am 28.07.2015 um 03:08 schrieb Andy Lutomirski: > On Mon, Sep 1, 2014 at 10:39 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> This fixes virtio on Xen guests as well as on any other platform >> that uses virtio_pci on which physical addresses don't match bus >> addresses. >> >> This can be tested with: >> >> virtme-run --xen xen --kimg arch/x86/boot/bzImage --console >> >> using virtme from here: >> >> https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git >> >> Without these patches, the guest hangs forever. With these patches, >> everything works. >> > > Dusting off an ancient thread. > > Now that the dust has accumulated^Wsettled, is it worth pursuing this? > I think the situation is considerably worse than it was when I > originally wrote these patches: I think that QEMU now supports a nasty > mode in which the guest's PCI bus appears to be behind an IOMMU but > the virtio devices on that bus punch straight through that IOMMU. > > I have a half-hearted port to modern kernels here: > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=virtio_ring_xen > > I didn't implement DMA API access for virtio_pci_modern, and I have no > idea what to do about detecting whether a given virtio device honors > its IOMMU or not. I think its really tricky. Looking at where virtio came from, the virtio ring was always native access without IOMMU. This was true for the early lguest things and then the early s390 transport, (which is quite close to the lguest interface). virtio-pci used the same scheme - ignoring all iommu considerations. I understand that for PCI we actually might want to follow iommu restrictions from a correctness and security point of view and from the ccw point of view we do not. No idea about virtio-mmio. I think the proper way of handling this is to take this into the TC for virtio - dont know what would be the right thing to do. A feature bit, always iommu for pci, something else? Michael, Conny, do you agree? Christian _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization