I'm happy to try this out, but it will take me some time to brush up  
on how to patch a kernel with the xen sources goes. I'll get back to  
you.

Thanks,
-Guil

Quoting Ian Campbell <[EMAIL PROTECTED]>:

> On Tue, 2007-05-01 at 19:41 -0500, Guil Barros wrote:
>> Note, I am moving this thread over here from ivtv-users in hopes that
>> it gets some attention/fixing :) For further info please see the
>> ivtv-users archive.
>
> Thinking about it a bit further -- I think the problem is more likely
> with the "swiotlb=foo" options not working, without it the ivtv driver
> failure is somewhat expected.
>
> The reason for the failure is that Xen to disallow multipage contiguous
> allocations for non-privileged domUs. Unfortunately a swiotlb is
> precisely a multipage contiguous allocation.
>
> It seems that the way to become a "privileged domU" is to have a
> non-empty set of I/O capabilities and that doing PCI pass-through should
> cause this to happen. (I presume you are passing the PVR device
> through).
>
> At least on 3.0.5 this doesn't seem to happen correctly. I see you are
> using 3.0.3 but the code looks pretty similar on the hypervisor and
> kernel side so that just leaves the tools/xend etc which isn't an area I
> know much about...
>
> You could take this to xen-devel where someone might have some more
> insight.
>
> If you are comfortable rebuilding the hypervisor you could try the patch
> below to confirm this is the issue. It will make all domains
> privileged...
>
> Ian.
>
> diff -r 2678e31d20f3 xen/include/xen/iocap.h
> --- a/xen/include/xen/iocap.h Wed May 02 09:42:43 2007 -0700
> +++ b/xen/include/xen/iocap.h Wed May 02 20:02:38 2007 +0100
> @@ -29,7 +29,7 @@
>      rangeset_contains_singleton((d)->irq_caps, i)
>
>  #define multipage_allocation_permitted(d)               \
> -    (!rangeset_is_empty((d)->iomem_caps))
> +    (1 || !rangeset_is_empty((d)->iomem_caps))
>
>  /*
>   * Until TLB flushing issues are sorted out we consider it unsafe for
>
> --
> Ian Campbell
>
> RELATIVES!!
>
>
> _______________________________________________
> ivtv-devel mailing list
> [email protected]
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>





_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Reply via email to