Re: Xen 4.2.0-rc4 issues with DVB tuner

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

On Tue, Sep 18, 2012 at 08:26:33PM +0200, Javier Marcet wrote:
> On Tue, Sep 18, 2012 at 7:17 PM, Konrad Rzeszutek Wilk
> <konrad@kernel.org> wrote:
> 
> >> 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?
> 
> The output contains data, part of the mpeg stream without any continuity.
> 
I see.
> >> 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?
> 
> Bingo Konrad! That was it :) At least I have just applied the patch,
> rebooted under Xen and this time I got a good dump.

Woohoo!
> 
> Right now I have my usual system running flawlessly under Xen. Time to
> take a look again at the suspend/resume issue which I nearly had
> working a few days ago.

Keep in mind that for the suspend/resume you need out of mainline
patches for right now. I hadn't yet upstreamed all the parts. They are
in  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
devel/acpi-s3.vXX (I believe 11 would apply cleanly to your tree?)

Keep in mind that there were some bugs in Xen 4.2 in regards to resume.
Look on xen-devel for emails between Jan and Ben Guthro.
> 
> Thanks a lot for all your help :)
> 
> P.S. I'm going to post this info on the linux media mailing list.

If you could CC me on it I can provide the technical explanation
for the 'DMA-API-ing the vmalloc_32' call.