Re: [Xen-devel] Re: Fire-wire passthrough with Linux pv-ops (2.6.31.1)

["Mr. Teo En Ming (Zhang Enming)" <space.time.universe@xxxxxxxxx>]

Hi Konrad,

I have filed a bug report for the firewire controller passthrough issue at http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1539 and also CCed to you and Weidong.

>Uuhh.. What did 'info blocks' (or maybe it is 'info block') tell you? >Did
>you look up any guides on how to do this? How do you know the >guest
>did not detect the CD change? Did you try to do a read on it?
>Like 'sg_readcap /dev/sr0' or 'dd if=/dev/sr0 of=/tmp/temp.iso' >within the guest?

For the case of "phy:/dev/sr0,hdc:cdrom,r" in domU config, i.e. using the physical host CD-ROM/DVD drive, if I want to change physical CD/DVD, I have no problems doing it with "eject" and "change hdc" commands. I can successfully change media.

The problem exists with ISO image files, in the case of "file:/path/to/dvd-image.iso,hdc:cdrom.r" in domU config. If you want to change ISO files, it cannot be done at all. After executing eject and change hdc commands, QEMU console will still report "not inserted". I have done it many times. If you try to mount the cd/dvd in domU, it will fail because the change of ISO file is not successful.

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics) BEng(Hons)(Mechanical Engineering)
Alma Maters:
(1) Singapore Polytechnic
(2) National University of Singapore
My Primary Blog: http://teo-en-ming-aka-zhang-enming.blogspot.com
My Secondary Blog: http://enmingteo.wordpress.com
My Youtube videos: http://www.youtube.com/user/enmingteo
Email: space.time.universe@xxxxxxxxx
Mobile Phone (Starhub Prepaid): +65-8369-2618
Street: Bedok Reservoir Road
Country: Singapore

On Tue, Nov 3, 2009 at 12:05 AM, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:

> >Can you provide the lspci -vv output of the Dom0 and >DomU, please?

.. snip ..

>     Region 0: Memory at d3801000 (32-bit, non-prefetchable) [size=4K]
>     Region 1: Memory at d3800000 (32-bit, non-prefetchable) [size=256]

.. snip ..

>     Region 0: Memory at e3001000 (32-bit, non-prefetchable) [size=4K]
>     Region 1: Memory at e3002000 (32-bit, non-prefetchable) [size=4K]

That is weird. The second region is at the wrong location (unless
QEMU actually does some copying after each MMIO operation..).

I think what you saw before in the QEMU is a good hint. It could
be that the QEMU code assumes the BARs addresses have to be
in an increased order, whilst in this case it is the reverse.

>     Capabilities: [44] Power Management version 2
>         Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>         Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
>     Kernel driver in use: ohci1394
>     Kernel modules: ohci1394
>
>
> > - cat /proc/interrupts (from Dom0) _before_ you launch >any guests or
> >  call bind any devices to the pcistub/pciback.

>  22:     387742          0  xen-pirq-ioapic-level  HDA Intel, firewire_ohci

All right. You probably need to unload your sound card first in the DomO
and pass it to the guest as well. But I vaguely remember you saying that
you do that already - so I think this is OK.

.. snip ..

>  36:          0          0   IO-APIC-fasteoi   ohci1394

That looks weird at first, but fasteoi == level, so that is OK.

I think the issue you pointed out earlier, where the error about
the BARs was printed, is the culprit. I am not going to get to this
until I am done with the pciback/pcifront work. But it could be
that somebody else will pick this bug up in the interim.

Can you open a bug on this (http://bugzilla.xensource.com/) and CC me on it?
Please include the qemu logs, the dmesg log, /proc/interrupts, lspci -vvv,
and anything else you can think off.  That way I won't forget about it.


.. snip ..

> I am running pv-ops dom0 kernel 2.6.31.5 now. There appears to be some
> sluggishness/unresponsiveness with this kernel after I have started a HVM
> guest.
>
> By the way, can you also help me to solve this problem as well?
>
> http://lists.xensource.com/archives/html/xen-devel/2009-11/msg00044.html

Uuhh.. What did 'info blocks' (or maybe it is 'info block') tell you? Did
you look up any guides on how to do this? How do you know the guest
did not detect the CD change? Did you try to do a read on it?
Like 'sg_readcap /dev/sr0' or 'dd if=/dev/sr0 of=/tmp/temp.iso' within the guest?

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel