On Tue, Apr 29, 2008 at 01:37:29PM +0300, Amit Shah wrote:
> dma_alloc_coherent() doesn't call dma_ops->alloc_coherent in case no
> IOMMU translations are necessary.
I always thought this was a huge wart in the x86-64 DMA ops. Would
there be strong resistance to fixing it so that alloc_coherent
m
On Wed, Apr 30, 2008 at 01:48:38AM +0300, Avi Kivity wrote:
> Amit Shah wrote:
>>
+ if (is_error_page(host_page)) {
+ printk(KERN_INFO "%s: gfn %p not valid\n",
+ __func__, (void *)page_gfn);
+ r = -1;
>>> r = -1 is not really infor
Amit Shah wrote:
>
>>> + if (is_error_page(host_page)) {
>>> + printk(KERN_INFO "%s: gfn %p not valid\n",
>>> + __func__, (void *)page_gfn);
>>> + r = -1;
>>>
>> r = -1 is not really informative. Better use some meaningful error.
>>
>
> The error's
On Tuesday 29 April 2008 20:14:16 Glauber Costa wrote:
> Amit Shah wrote:
> > +static struct kvm_pv_dma_map*
> > +find_pci_pv_dmap(struct list_head *head, dma_addr_t dma)
> > +{
>
> might be better to prefix those functions with kvm? Even though they are
> static, it seems to be the current practi
Amit Shah wrote:
> We introduce three hypercalls:
> 1. When the guest wants to check if a particular device is an assigned device
>(this is done once per device by the guest to enable / disable hypercall-
>based translation of addresses)
>
> 2. map: to convert guest phyical addresses to ho
On Tuesday 29 April 2008 19:01:32 Andi Kleen wrote:
> Amit Shah <[EMAIL PROTECTED]> writes:
> > +const struct dma_mapping_ops *orig_dma_ops;
>
> I suspect real dma ops stacking will need some further thought than
> your simple hacks
Yes; that's something we're planning to do.
> Haven't read furt
On Tuesday 29 April 2008 18:44:23 Andi Kleen wrote:
> Amit Shah <[EMAIL PROTECTED]> writes:
> > diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
> > index 388b113..678cafb 100644
> > --- a/arch/x86/kernel/pci-dma.c
> > +++ b/arch/x86/kernel/pci-dma.c
> > @@ -443,6 +443,17 @@ dma_a
Amit Shah <[EMAIL PROTECTED]> writes:
> +
> +static struct page *page;
> +static unsigned long page_gfn;
Bad variable names
> +
> +const struct dma_mapping_ops *orig_dma_ops;
I suspect real dma ops stacking will need some further thought than
your simple hacks
> +
> + match = find_matching_pt
Amit Shah <[EMAIL PROTECTED]> writes:
> This patchset implements PVDMA for handling DMA requests from
> devices assigned to the guest from the host machine.
You forgot to post a high level design overview of how this works,
what it is good for, what are the design trade offs etc.?
Include that
Amit Shah <[EMAIL PROTECTED]> writes:
> diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
> index 388b113..678cafb 100644
> --- a/arch/x86/kernel/pci-dma.c
> +++ b/arch/x86/kernel/pci-dma.c
> @@ -443,6 +443,17 @@ dma_alloc_coherent(struct device *dev, size_t size,
> dma_addr_t *dm
We introduce three hypercalls:
1. When the guest wants to check if a particular device is an assigned device
(this is done once per device by the guest to enable / disable hypercall-
based translation of addresses)
2. map: to convert guest phyical addresses to host physical address to pass o
dma_alloc_coherent() doesn't call dma_ops->alloc_coherent in case no IOMMU
translations are necessary. However, if the device doing the DMA is a
physical device assigned to the guest OS by the host, we need to map
all the DMA addresses to the host machine addresses. This is done via
hypercalls to t
This patchset implements PVDMA for handling DMA requests from
devices assigned to the guest from the host machine.
They're also available from
git-pull git://git.kernel.org/pub/scm/linux/kernel/git/amit/kvm.git pvdma
These patches are based on my pci-passthrough tree, which is available
from
g
We make the dma_mapping_ops structure to point to our structure
so that every DMA access goes through us.
We make a hypercall for every device that does a DMA operation
to find out if it is an assigned device -- so that we can make
hypercalls on each DMA access. The result of this hypercall is
cac
14 matches
Mail list logo
