Mailing List Archive

hvr-1600 in Xen domU ?
After weeks of headaches trying to get my HVR-1600 to work, I finally
determined with help from this list that the H77 chipset on my
motherboard was the root of my problems, so I replaced the board. I
am now trying to set up my MythTV backend in a Xen domU after
verifying that it can capture outside of Xen and in the Xen dom0 host.
I can tune to channels and I get data when I cat /dev/video0 ... but
the data doesn't seem to be valid video.

Does anybody have input on how I can work towards a resolution on
this? I have driver debug output if interested. I would really like
to virtualize my mythbackend so I can isolate the role from the other
apps the system will be running (such as e-mail).

-Robert

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: hvr-1600 in Xen domU ? [ In reply to ]
On Sat, 2012-07-07 at 12:44 -0500, Robert Rust wrote:
> After weeks of headaches trying to get my HVR-1600 to work, I finally
> determined with help from this list that the H77 chipset on my
> motherboard was the root of my problems, so I replaced the board. I
> am now trying to set up my MythTV backend in a Xen domU after
> verifying that it can capture outside of Xen and in the Xen dom0 host.

What is the difference between Xen domain dom0 and domU (for a Xen newb
like me)?


> I can tune to channels and I get data when I cat /dev/video0 ... but
> the data doesn't seem to be valid video.

You may wan to try using v4l2-ctl to enumerate the controls (with menu
options) and then changes the card to generate an MPEG2 TS instead of
the default MPEG2 PS. A TS is more robust to small amounts of data loss
than a PS, so maybe things will be a little better.


> Does anybody have input on how I can work towards a resolution on
> this?

Note the CX23418 is very latency sensitive. If the guest responds too
slowly to CX23418 interrupts, it will miss the CX23418 mailbox payload
data and hence lose video buffer data. The CX23418 won't wait forever
for the OS driver and will move on. (This is a firmware bug IMO, but
likely considered a required feature if you ask Conexant).

Regards,
Andy

> I have driver debug output if interested. I would really like
> to virtualize my mythbackend so I can isolate the role from the other
> apps the system will be running (such as e-mail).



_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: hvr-1600 in Xen domU ? [ In reply to ]
On Sun, Jul 8, 2012 at 2:28 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> On Sat, 2012-07-07 at 12:44 -0500, Robert Rust wrote:
>> After weeks of headaches trying to get my HVR-1600 to work, I finally
>> determined with help from this list that the H77 chipset on my
>> motherboard was the root of my problems, so I replaced the board. I
>> am now trying to set up my MythTV backend in a Xen domU after
>> verifying that it can capture outside of Xen and in the Xen dom0 host.
>
> What is the difference between Xen domain dom0 and domU (for a Xen newb
> like me)?
>
>
>> I can tune to channels and I get data when I cat /dev/video0 ... but
>> the data doesn't seem to be valid video.
>
> You may wan to try using v4l2-ctl to enumerate the controls (with menu
> options) and then changes the card to generate an MPEG2 TS instead of
> the default MPEG2 PS. A TS is more robust to small amounts of data loss
> than a PS, so maybe things will be a little better.
>
>
>> Does anybody have input on how I can work towards a resolution on
>> this?
>
> Note the CX23418 is very latency sensitive. If the guest responds too
> slowly to CX23418 interrupts, it will miss the CX23418 mailbox payload
> data and hence lose video buffer data. The CX23418 won't wait forever
> for the OS driver and will move on. (This is a firmware bug IMO, but
> likely considered a required feature if you ask Conexant).
>
> Regards,
> Andy
>

Andy, I did manage to get it to work. After trying my PVR-250 and
getting DMA timemouts, I noticed I missed passing a kernel parameter
required for PCI Passthrough (iommu=soft). After fixing that and
putting the HVR-1600 back in, I encountered the known issue with
missing audio, which resolved itself after the first capture (the
MythTV wiki has a note on that as well).

In regards to dom0 vs. domU ... I think the best way of explaining it
(assuming I understand it correctly ... I'm rather new to Xen myself)
is that the dom0 is the "host" (sits 1 layer above the actual Xen
kernel) and so has direct access to hardware out-of-the-box and the
domU is a virtual host which requires tricks and hardware/software
support to pass it bare hardware.

Thanks for the assistance!
-Robert

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: hvr-1600 in Xen domU ? [ In reply to ]
On Sun, 2012-07-08 at 15:28 -0400, Andy Walls wrote:
> On Sat, 2012-07-07 at 12:44 -0500, Robert Rust wrote:
> > After weeks of headaches trying to get my HVR-1600 to work, I finally
> > determined with help from this list that the H77 chipset on my
> > motherboard was the root of my problems, so I replaced the board. I
> > am now trying to set up my MythTV backend in a Xen domU after
> > verifying that it can capture outside of Xen and in the Xen dom0 host.
>
> What is the difference between Xen domain dom0 and domU (for a Xen newb
> like me)?
>
>

Ah, found it:
http://wiki.xen.org/wiki/XenOverview#Introduction_to_Xen_Architecture

"... Domain 0) is a specialized Virtual Machine that 0 has special
privileges like the capability to access the hardware directly, handles
all access to the system’s I/O functions ..."

"... Xen [domU] guests are totally isolated from the hardware: in other
words, they have no privilege to access hardware or I/O functionality.
Thus, they are also called unprivileged domain (or DomU)."

> > I can tune to channels and I get data when I cat /dev/video0 ... but
> > the data doesn't seem to be valid video.


> > Does anybody have input on how I can work towards a resolution on
> > this?

This page looks helpful:

http://wiki.xen.org/wiki/XenPCIpassthrough

If your linux kernel panics because the cx18 driver asks for more DMA
buffer space than the SWIOTLB (Software IOMMU) in Linux can provide, you
can cut down on the number and size of buffers for CX23418 data streams
using cx18 module options.

Also the Linux Software IOMMU requires copies of DMA buffres by the CPU,
so performance will stink, unless you have lots of excess horsepower.

Please note that the CX23418 acts as a DMA master on the PCI bus. When
the cx18 driver tells the CX23418 about where the DMA buffers are, they
must be the correct PCI address-space addresses that the CX23418 chip
and firmware can actually DMA into. If you have a Linux kernel running
in any other Xen (dom0 or domU) guest, you should probably blacklist the
cx18 driver in that guest, so that instance of the cx18 driver doesn't
also load the CX23418 with DMA addresses to use or otherwise change the
CX23418's System Control Block (SCB) area.

(In case you are interested, this is the function in the cx18 driver
where the driver tells the firmware about the DMA addresses of buffers:

http://git.linuxtv.org/media_tree.git/blob/staging/for_v3.6:/drivers/media/video/cx18/cx18-queue.c#l277

and this is the function that initializes the SCB on driver probe:

http://git.linuxtv.org/media_tree.git/blob/staging/for_v3.6:/drivers/media/video/cx18/cx18-scb.c#l27
)


> Note the CX23418 is very latency sensitive. If the guest responds too
> slowly to CX23418 interrupts, it will miss the CX23418 mailbox payload
> data and hence lose video buffer data. The CX23418 won't wait forever
> for the OS driver and will move on. (This is a firmware bug IMO, but
> likely considered a required feature if you ask Conexant).

The above still applies. Low interrupt latency response by the cx18
driver in the domU guest is important for glitch free recordings.

Regards,
Andy



_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: hvr-1600 in Xen domU ? [ In reply to ]
On Sun, Jul 8, 2012 at 4:56 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> On Sun, 2012-07-08 at 15:28 -0400, Andy Walls wrote:
>> On Sat, 2012-07-07 at 12:44 -0500, Robert Rust wrote:
>> > After weeks of headaches trying to get my HVR-1600 to work, I finally
>> > determined with help from this list that the H77 chipset on my
>> > motherboard was the root of my problems, so I replaced the board. I
>> > am now trying to set up my MythTV backend in a Xen domU after
>> > verifying that it can capture outside of Xen and in the Xen dom0 host.
>>
>> What is the difference between Xen domain dom0 and domU (for a Xen newb
>> like me)?
>>
>>
>
> Ah, found it:
> http://wiki.xen.org/wiki/XenOverview#Introduction_to_Xen_Architecture
>
> "... Domain 0) is a specialized Virtual Machine that 0 has special
> privileges like the capability to access the hardware directly, handles
> all access to the system’s I/O functions ..."
>
> "... Xen [domU] guests are totally isolated from the hardware: in other
> words, they have no privilege to access hardware or I/O functionality.
> Thus, they are also called unprivileged domain (or DomU)."
>
>> > I can tune to channels and I get data when I cat /dev/video0 ... but
>> > the data doesn't seem to be valid video.
>
>
>> > Does anybody have input on how I can work towards a resolution on
>> > this?
>
> This page looks helpful:
>
> http://wiki.xen.org/wiki/XenPCIpassthrough
>
> If your linux kernel panics because the cx18 driver asks for more DMA
> buffer space than the SWIOTLB (Software IOMMU) in Linux can provide, you
> can cut down on the number and size of buffers for CX23418 data streams
> using cx18 module options.
>
> Also the Linux Software IOMMU requires copies of DMA buffres by the CPU,
> so performance will stink, unless you have lots of excess horsepower.
>
> Please note that the CX23418 acts as a DMA master on the PCI bus. When
> the cx18 driver tells the CX23418 about where the DMA buffers are, they
> must be the correct PCI address-space addresses that the CX23418 chip
> and firmware can actually DMA into. If you have a Linux kernel running
> in any other Xen (dom0 or domU) guest, you should probably blacklist the
> cx18 driver in that guest, so that instance of the cx18 driver doesn't
> also load the CX23418 with DMA addresses to use or otherwise change the
> CX23418's System Control Block (SCB) area.
>
> (In case you are interested, this is the function in the cx18 driver
> where the driver tells the firmware about the DMA addresses of buffers:
>
> http://git.linuxtv.org/media_tree.git/blob/staging/for_v3.6:/drivers/media/video/cx18/cx18-queue.c#l277
>
> and this is the function that initializes the SCB on driver probe:
>
> http://git.linuxtv.org/media_tree.git/blob/staging/for_v3.6:/drivers/media/video/cx18/cx18-scb.c#l27
> )
>

Would this preclude passing a second HVR-1600 to a different DomU ?
DomU #2 sees the HVR-1600 and loads the cx18 module for it, but I
can't capture valid video. If you're wondering why I don't pass it to
DomU #1 (in which the first HVR-1600 works fine), I can't seem to get
DomU #1 to see both cards at once.
In DomU #2, I get messages like the following:
Sep 23 16:23:59 merry kernel: [ 1131.227956] cx18-0: Skipped encoder
MPEG, MDL 9, 62 times - it must have dropped out of rotation

Thoughts? I'm also going to try pursuing why I can't pass both cards
to one DomU.

-Robert

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users