Re: Xen 4.2.0-rc4 issues with DVB tuner

[Konrad Rzeszutek Wilk <konrad@kernel.org>]

On Tue, Sep 18, 2012 at 10:41:37AM +0200, Javier Marcet wrote:
> On Tue, Sep 18, 2012 at 2:08 AM, Javier Marcet <jmarcet@gmail.com> wrote:
> 
> Hi,
> 
> > Still nothing. Not even enabling the debug options within the DVB
> > subsystem I get
> > anything which doesn't look perfectly normal, exactly like when it's
> > working fine.
> >
> > I have just posted a message on the linux media mailing list looking
> > for some help
> > from the dvb maintainers.
> 
> I have some news from the linux-media mailing list. There, Devin Heitmueller,
> said this:
> 
> """
> > Initially I thought Xen would be the cause of the problem, but after
> > having written on
> > the Xen development mailing list and talked about it with a couple
> > developers, it isn't
> > very clear where the problem is. So far I haven't been able to get the
> > smallest warning
> > or error.
> 
> This is a very common problem when attempting to use any PCI/PCIe
> tuner under a hypervisor.  Essentially the issue is all of the
> virtualization solutions provide very poor interrupt latency, which
> results in the data being lost.
> 
> Devices delivering a high bitrate stream of data in realtime are much
> more likely for this problem to be visible since such devices have
> very little buffering (it's not like a hard drive controller where it
> can just deliver the data slower).  The problem is not specific to the
> cx23885 - pretty much all of the PCI/PCIe bridges used in tuner cards
> work this way, and they cannot really be blamed for expecting to run
> in an environment with really crappy interrupt latency.
> 
> I won't go as far as to say, "abandon all hope", but you're not really
> likely to find any help in this forum.
> """

Not sure about the interrupt latency. If you run this little program
http://darnok.org/xen/read_interrupts.c
when capturing in both dom0 and in baremetal are the rate about the
same?
> 
> What I don´t understand is how graphics pass through even works
> and a tuner card has problems due to the introduced latencies in the
> IRQs.

The latency is very very miniscule. One could actually verify that this
is a problem by inserting said latency in the driver so that under
baremetal the latency would show up.

But the other issue is that if the data is being lost you would at least
get some. So the buffers ought to have "something" in them? Maybe that
depends on what compression you use on the coder? If you jus do YUV420
or the RGB variants and just do a simple 'cat /dev/vide0 > /tmp/file'
does the output contain anything? Or is just a blob of empty data?

> 
> Do you have any more info about this?

The other issue could be related to the vmalloc_32 being in usage
and not using the DMA API.

I recall posting a patch for this .. Ah:
http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html

Perhaps this is the issue?