Re: Graphics card pass-through working with two pass pci-initialization

["André Weidemann" <Andre.Weidemann@web.de>]

Hi,

On 28.05.2011 10:18, Jan Kiszka wrote:
> On 2011-05-26 23:19, André Weidemann wrote:
>> On 27.05.2011 21:50, André Weidemann wrote:
>>> On 27.05.2011 21:40, André Weidemann wrote:
>>>
>>>> If I am not mistaken then the graphics card needs 2 bars, one with 256MB
>>>> and one with 128K. The sound card then needs 1 bar with 16K of PCI
>>>> memory.
>>>> How big is the PCI memory with seabios?
>>>> Is there really not enough space to "squeeze" in those extra 16K?
>>>
>>> I obviously forgot to add up the other memory that is used...
>>> 32MB go to the standard VGA card. Running qemu-kvm with "-vga none" did
>>> not work, so I left it in. And the e1000 NIC needs another 128K.
>>>
>>> I'll see if I can get rid of the standard VGA card. I guess that should
>>> free enough memory for the sound card.
>>
>> I did some more testing by starting the VM with the paramter "-vga none"
>> and passed both the VGA card and the sound card to it. With this option
>> the VM did not boot,
>
> Where did it hang, ie. what IP was reported by info cpus?

I added some debug options and found out, that the VM hangs when trying 
to initialize the graphics card ROM.
See here:
http://pastebin.com/S9a8uQfU

And some additional info here:

http://pastebin.com/AC4rw8Ek (info cpus/registers)
http://pastebin.com/yYkn8jL2 (info pci)

>> but I could use the monitor to take a look at the
>> PCI bar assignment. Even though the memory for the standard VGA card is
>> freed, the soundcard does not seem to get the 16K bar it needs. "info
>> pci" for the sound card still looks like this:
>>   Bus  0, device   5, function 0:
>>      Audio controller: PCI device 8086:3a3e
>>        IRQ 10.
>>        BAR0: 32 bit memory at 0xffffffffffffffff [0x00003ffe].
>>
>> Does anyone have an idea why there was no bar assigned?
>
> Maybe Gerd's patches aren't sufficient and you still need to change
> BUILD_MAX_HIGHMEM. See the hacks in
> http://git.kiszka.org/?p=seabios.git;a=shortlog;h=refs/heads/vga-assign,
> either replacing Gerd's patches or combined with them (I haven't checked
> if the latter makes sense).

I do not have access to the machine until tomorrow. I'm curious to see 
if extending the PCI memory window will cure the problem.

>> Can the kernel be too old? (2.6.35.7.)
>
> It would be good to check the latest kvm kernel to see if that oops is
> still present. In that case, please try to collect the backtrace via
> serial console, hopefully complete then. We may have an resource cleanup
> issue there.

I will see if I can upgrade to the latest kernel tomorrow.

>>
>> Just to test whether or not two devices can be assigned, I passed
>> through 2 sound cards. (There is an onbard sound card and the Radeon has
>> one too).
>>
>> Each sound card gets its bar assigned as you can see:
>>    Bus  0, device   4, function 0:
>>      Audio controller: PCI device 1002:aa80
>>        IRQ 10.
>>        BAR0: 32 bit memory at 0xfebf0000 [0xfebf3fff].
>>        id ""
>>    Bus  0, device   5, function 0:
>>      Audio controller: PCI device 8086:3a3e
>>        IRQ 10.
>>        BAR0: 32 bit memory at 0xfebf4000 [0xfebf7fff].
>>
>> but the sound cards do not show inside the Windows VM.
>>
>> With both sound cards still passed to the VM I then booted an Ubuntu
>> 10.10 image instead of Windows7. It got as far as starting gdm, but then
>> the entire host and VM became very slow.
>> The last message I saw on the terminal before gdm started was this:
>> [   23.030016 ] hda_intel: azx_get_response timeout, switching to
>> single_cmd mode: last cmd=0x000f0000
>> [   29.290017 ] hda_intel: azx_get_response timeout, switching to
>> single_cmd mode: last cmd=0x200f0000
>
> Likely some IRQ issue. Please check if latest qemu-kvm.git +
> http://thread.gmane.org/gmane.comp.emulators.qemu/102540 makes any
> difference.

See above comments. I will try this tomorrow.

Regards
  André