> >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
|
Home