From mboxrd@z Thu Jan 1 00:00:00 1970 From: sheng qiu Subject: Re: AMD KVM Pci Passthrough reports device busy Date: Tue, 5 Jun 2012 20:32:15 -0500 Message-ID: References: <1338867845.23475.168.camel@bling.home> <201206051039.q55AdXda002609@mail.maya.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Alex Williamson , Joerg.Roedel@amd.com, Chris Sanders , kvm@vger.kernel.org To: Andreas Hartmann Return-path: Received: from mail-yx0-f174.google.com ([209.85.213.174]:49440 "EHLO mail-yx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751845Ab2FFBcQ convert rfc822-to-8bit (ORCPT ); Tue, 5 Jun 2012 21:32:16 -0400 Received: by yenm10 with SMTP id m10so4591317yen.19 for ; Tue, 05 Jun 2012 18:32:16 -0700 (PDT) In-Reply-To: <201206051039.q55AdXda002609@mail.maya.org> Sender: kvm-owner@vger.kernel.org List-ID: test On Tue, Jun 5, 2012 at 5:39 AM, Andreas Hartmann wrote: > Hello Alex, > > thanks for your efforts! > > Maybe, you already know that I'm suffering the same problem :-( with = a > GA-990XA-UD3 (990X chipset). > > > On Mon, 04 Jun 2012 21:44:05 -0600 > Alex Williamson wrote: > [...] >> I have a setup with an AMD 990FX system and a spare PVR-350 card tha= t I >> installed to reproduce. =A0The sad answer is that it's nearly imposs= ible >> to assign PCI devices on these systems due to the aliasing of device= s >> below the PCIe-to-PCI bridge (PCIe devices are much, much easier to >> assign). =A0If you boot with amd_iommu_dump, you'll see some output = like >> this: >> >> AMD-Vi: =A0 DEV_ALIAS_RANGE =A0 =A0 =A0 =A0 =A0 =A0 =A0devid: 05:00.= 0 flags: 00 devid_to: 00:14.4 >> AMD-Vi: =A0 DEV_RANGE_END =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0devid: 05:1= f.7 > > here: > AMD-Vi: =A0 DEV_ALIAS_RANGE =A0 =A0 =A0 =A0 devid: 06:00.0 flags: 00 = devid_to: 00:14.4 > AMD-Vi: =A0 DEV_RANGE_END =A0 =A0 =A0 =A0 =A0 devid: 06:1f.7 > > > This means according to your description, the following devices have = to > be unbound here, too (0000:06:07.0 is the device I want to passthroug= h): > > 0000:00:14.0 -> ../../../../devices/pci0000:00/0000:00:14.0 > 0000:00:14.1 -> ../../../../devices/pci0000:00/0000:00:14.1 > 0000:00:14.2 -> ../../../../devices/pci0000:00/0000:00:14.2 > 0000:00:14.3 -> ../../../../devices/pci0000:00/0000:00:14.3 > 0000:00:14.4 -> ../../../../devices/pci0000:00/0000:00:14.4 > 0000:00:14.5 -> ../../../../devices/pci0000:00/0000:00:14.5 > 0000:06:07.0 -> ../../../../devices/pci0000:00/0000:00:14.4/0000:06:0= 7.0 > > > These are the following additional devices: > > 00:14.0 SMBus: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus Contr= oller (rev 42) > 00:14.1 IDE interface: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8= x0/SB9x0 IDE Controller (rev 40) (prog-if 8a [Master SecP PriP]) > 00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azal= ia (Intel HDA) (rev 40) > 00:14.3 ISA bridge: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/= SB9x0 LPC host controller (rev 40) > 00:14.4 PCI bridge: Advanced Micro Devices [AMD] nee ATI SBx00 PCI to= PCI Bridge (rev 40) (prog-if 01 [Subtractive decode]) > 00:14.5 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB= 8x0/SB9x0 USB OHCI2 Controller (prog-if 10 [OHCI]) > > > Among them is the sound device and the USB device - no good idea to > disable them on a desktop. > > Disabling 00:14.1 seems to be possible (rmmod pata_atiixp works), but > I'm getting errors after rebooting the system (the filesystems haven'= t > been cleanly unmounted during shutdown). > > Anyway, I would have tested it, but I'm getting a compile error while > compiling qemu. It complains about missing pci/header.h while > processing hw/vfio_pci.c:49:24. I can't find any pci/header.h. Where > should it come from? > > [...] > >> The downside is that VFIO is strict about >> multifunction devices supporting ACS to prevent peer-to-peer between >> domains, so will require all of the 14.x devices to be bound to pci-= stub >> as well. =A0On my system, this includes an smbus controller, audio d= evice, >> lpc controller, and usb device. =A0If AMD could confirm this device >> doesn't allow peer-to-peer between functions, we could relax this >> requirement a bit. > > Please Joerg, could you take a look at this problem? > > > Thanks, > kind regards, > Andreas > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at =A0http://vger.kernel.org/majordomo-info.html --=20 Sheng Qiu Texas A & M University Room 332B Wisenbaker email: herbert1984106@gmail.com College Station, TX 77843-3259