RFC: Paravirtualized DMA accesses for KVM - Kernel

This is a discussion on RFC: Paravirtualized DMA accesses for KVM - Kernel ; Of all the DMA calls, only dma_alloc_coherent might not actually call dma_ops->alloc_coherent. We make sure that gets called if the device that's being worked on is a PV device Signed-off-by: Amit Shah --- arch/x86/kernel/pci-dma_64.c | 13 +++++++++++++ 1 files changed, ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: RFC: Paravirtualized DMA accesses for KVM

  1. [PATCH 5/8] KVM: PVDMA: Update dma_alloc_coherent to make it paravirt-aware

    Of all the DMA calls, only dma_alloc_coherent might not actually
    call dma_ops->alloc_coherent. We make sure that gets called
    if the device that's being worked on is a PV device

    Signed-off-by: Amit Shah
    ---
    arch/x86/kernel/pci-dma_64.c | 13 +++++++++++++
    1 files changed, 13 insertions(+), 0 deletions(-)

    diff --git a/arch/x86/kernel/pci-dma_64.c b/arch/x86/kernel/pci-dma_64.c
    index aa805b1..d4b1713 100644
    --- a/arch/x86/kernel/pci-dma_64.c
    +++ b/arch/x86/kernel/pci-dma_64.c
    @@ -11,6 +11,7 @@
    #include
    #include
    #include
    +#include

    int iommu_merge __read_mostly = 1;
    EXPORT_SYMBOL(iommu_merge);
    @@ -134,6 +135,18 @@ dma_alloc_coherent(struct device *dev, size_t size, dma_addr_t *dma_handle,
    memset(memory, 0, size);
    if (!mmu) {
    *dma_handle = virt_to_bus(memory);
    + if (unlikely(dma_ops->is_pv_device)
    + && unlikely(dma_ops->is_pv_device(dev, dev->bus_id))) {
    + void *r;
    + r = dma_ops->alloc_coherent(dev, size,
    + dma_handle,
    + gfp);
    + if (r == NULL) {
    + free_pages((unsigned long)memory,
    + get_order(size));
    + memory = NULL;
    + }
    + }
    return memory;
    }
    }
    --
    1.5.3

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. RFC: Paravirtualized DMA accesses for KVM


    This patchset is work in progress and is sent out for comments.

    Guests within KVM can have paravirtualized DMA access. I've tested
    the e1000 driver, and that works fine. A few problems/conditions to
    get things to work:

    - The pv driver should only be used as a module. If built into the
    kernel, It freezes during the HD bringup
    - Locks aren't taken on the host; multiple guests with passthrough
    won't work
    - Only 64 bit host and 64 bit guests are supported

    And there are several FIXMEs mentioned in the code, but none
    as grave as the ones already mentioned above.

    The bulk of the passthrough work is done in userspace (qemu). Patches
    will be sent shortly to the kvm-devel and qemu lists.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [kvm-devel] [PATCH 1/8] KVM: PVDMA Host: Handle reqeusts for guest DMA mappings

    On Wed, Nov 07, 2007 at 04:21:02PM +0200, Amit Shah wrote:
    > @@ -1649,6 +1913,15 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
    > }
    >
    > switch (nr) {
    > + case KVM_PV_DMA_MAP:
    > + ret = pv_map_hypercall(vcpu, a0, a1);
    > + break;
    > + case KVM_PV_DMA_UNMAP:
    > + ret = pv_unmap_hypercall(vcpu, a0);
    > + break;
    > + case KVM_PV_PCI_DEVICE:
    > + ret = pv_mapped_pci_device_hypercall(vcpu, a0);
    > + break;
    > default:
    > ret = -KVM_ENOSYS;
    > break;


    How does synchronization work with that design? I don't see a hypercall
    to synchronize de DMA buffers. It will only work if GART is used as the
    dma_ops backend on the host side and not with SWIOTLB. But GART can be
    configured away. Or do I miss something?

    Joerg

    --
    | AMD Saxony Limited Liability Company & Co. KG
    Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
    System | Register Court Dresden: HRA 4896
    Research | General Partner authorized to represent:
    Center | AMD Saxony LLC (Wilmington, Delaware, US)
    | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [kvm-devel] [PATCH 1/8] KVM: PVDMA Host: Handle reqeusts for guest DMA mappings

    On Monday 12 November 2007 21:25:22 Joerg Roedel wrote:
    > On Wed, Nov 07, 2007 at 04:21:02PM +0200, Amit Shah wrote:
    > > @@ -1649,6 +1913,15 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
    > > }
    > >
    > > switch (nr) {
    > > + case KVM_PV_DMA_MAP:
    > > + ret = pv_map_hypercall(vcpu, a0, a1);
    > > + break;
    > > + case KVM_PV_DMA_UNMAP:
    > > + ret = pv_unmap_hypercall(vcpu, a0);
    > > + break;
    > > + case KVM_PV_PCI_DEVICE:
    > > + ret = pv_mapped_pci_device_hypercall(vcpu, a0);
    > > + break;
    > > default:
    > > ret = -KVM_ENOSYS;
    > > break;

    >
    > How does synchronization work with that design? I don't see a hypercall
    > to synchronize de DMA buffers. It will only work if GART is used as the
    > dma_ops backend on the host side and not with SWIOTLB. But GART can be
    > configured away. Or do I miss something?


    A per-VM lock is needed while mapping or unmapping. It's one of the TODOs.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread