Re: [Qemu-devel] VFIO VGA test branches

[Maik Broemme <mbroemme@parallels.com>]

Hi Alex,

Maik Broemme <mbroemme@parallels.com> wrote:
> Hi Alex,
> 
> Alex Williamson <alex.williamson@redhat.com> wrote:
> > 
> > Good to hear.  It looks like you have the same motherboard as my AMD
> > test system.  An HD7850 in that system runs quite reliably with the
> > branches above although I do occasionally get VGA palette corruption.
> > 
> 
> Good to know. I'm using a Radeon HD7870 which works fine now. I have the
> same VGA palette corruption occasionally but only until Catalyst driver
> is loaded. So it happens sometimes during VGA init if Windows 7 boot
> logo is shown with very strange colors and went away if Catalyst driver
> is loaded.
> 
> > Are you still require -vga cirrus or do the -vga none, x-vga=on cases
> > work now too?  Thanks,
> > 
> 
> No longer required, -vga none with x-vga=on work on your branches fine
> now. Not sure if there was something more changed because with original
> Fedora 3.9.2 kernel it still doesn't work.
> 

Alex, I have a strange issue now with either the 'vfio-vga-reset'
branches or with the stable 3.9.4 kernel. This is my 'lspci' output:

00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) (rev 40)
01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 520] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GF119 HDMI Audio Controller (rev a1)
02:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Pitcairn [Radeon HD 7800]
02:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Cape Verde/Pitcairn HDMI Audio [Radeon HD 7700/7800 Series]

The '01:00.0' is my primary device used for Linux and '02:00.0' my
secondary for QEMU. Two new different problems:

1) If the 'nvidia.ko' binary driver is loaded for the first card, QEMU
immediately get stuck after startup and hangs with:

1140  futex(0x7f0ad9b21300, FUTEX_WAIT_PRIVATE, 2, NULL

I have the complete strace output if needed. After that I can only
terminate qemu with 'kill -9' and if I start it again the following
Oops occurs:

[  655.684121] ------------[ cut here ]------------
[  655.684134] WARNING: at lib/list_debug.c:29 __list_add+0x77/0xd0()
[  655.684151] Hardware name: GA-990FXA-UD3
[  655.684271] list_add corruption. next->prev should be prev (ffffffff81ca3d98), but was           (null). (next=ffff88041bc3fe08).
[  655.684477] Modules linked in: vhost_net macvtap macvlan tun arc4 md4 nls_utf8 cifs dns_resolver fscache vfio_pci vfio_iommu_type1 vfio bridge stp llc ip6table_filter ip6_tables it87 hwmon_vid snd_hda_codec_hdmi nvidia(POF) acpi_cpufreq mperf kvm_amd snd_hda_codec_realtek kvm crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hda_intel snd_hda_codec microcode edac_core snd_hwdep fam15h_power snd_seq edac_mce_amd snd_seq_device k10temp r8169 sp5100_tco snd_pcm mii i2c_piix4 snd_page_alloc snd_timer i2c_core snd soundcore mxm_wmi firewire_ohci firewire_core crc_itu_t wmi
[  655.685451] Pid: 2097, comm: qemu-system-x86 Tainted: PF          O 3.9.4-200.fc18.x86_64 #1
[  655.685642] Call Trace:
[  655.685738]  [<ffffffff8105f125>] warn_slowpath_common+0x75/0xa0
[  655.685851]  [<ffffffff8105f206>] warn_slowpath_fmt+0x46/0x50
[  655.685955]  [<ffffffff81316ef7>] __list_add+0x77/0xd0
[  655.686058]  [<ffffffff8108392c>] add_wait_queue+0x3c/0x60
[  655.686162]  [<ffffffff813f241d>] vga_get+0xdd/0x190
[  655.686266]  [<ffffffff81093e40>] ? try_to_wake_up+0x2d0/0x2d0
[  655.686373]  [<ffffffffa01ac625>] vfio_pci_vga_rw+0xb5/0x230 [vfio_pci]
[  655.686481]  [<ffffffffa01aa279>] vfio_pci_rw+0x39/0x80 [vfio_pci]
[  655.686587]  [<ffffffffa01aa30c>] vfio_pci_read+0x1c/0x20 [vfio_pci]
[  655.686701]  [<ffffffffa01a40e3>] vfio_device_fops_read+0x23/0x30 [vfio]
[  655.686814]  [<ffffffff811a01b9>] vfs_read+0xa9/0x180
[  655.686915]  [<ffffffff811a05ba>] sys_pread64+0x9a/0xb0
[  655.687018]  [<ffffffff81669f59>] system_call_fastpath+0x16/0x1b
[  655.687123] ---[ end trace a68eabc3660237b1 ]---

This is always reproducible. I know it is the binary driver and maybe
nobody cares but it is widely used. :)

2) If the 'nouveau.ko' driver is loaded it is even more strange. As soon
as I start qemu all my SATA links get a hard reset and kernel freezes.
No SysRQs are working anymore and only reboot helps. If needed I can
look if I can get some dumps from this freeze because it writes nothing
more to the disks.

But it is getting even more strange. I was putting the secondary card
in another PCI slot and then it started to work with nouveau module
loaded and passthrough ATI card to QEMU. But this worked only until I
started X server with nouveau X driver. As soon as X is running and I
started QEMU it hanged again in FUTEX_WAIT_PRIVATE.

3) Without loading 'nvidia.ko' or 'nouveau.ko' modules it works out of
the box with several start/stop cycles. However I have no X in this
case. ;)

Any ideas? :)

> > Alex
> > 
> 
> --Maik
> 

--Maik