From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755312Ab3BENb6 (ORCPT ); Tue, 5 Feb 2013 08:31:58 -0500 Received: from meriadoc.sigma-star.at ([178.63.61.2]:36726 "EHLO meriadoc.sigma-star.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754009Ab3BENb4 (ORCPT ); Tue, 5 Feb 2013 08:31:56 -0500 Message-ID: <1360071110.6200.19.camel@riven-lux.site> Subject: Re: DMAR faults from unrelated device when vfio is used From: David Gstir To: Alex Williamson Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, richard@sigma-star.at Date: Tue, 05 Feb 2013 14:31:50 +0100 In-Reply-To: <1359992968.11144.414.camel@bling.home> References: <1359972630.2498.21.camel@riven-lux.site> <1359992968.11144.414.camel@bling.home> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Montag, den 04.02.2013, 08:49 -0700 schrieb Alex Williamson: > Can you clarify what you mean by assign? Are you actually assigning the > root ports to the qemu guest (1c.0 & 1c.6)? vfio will require they be > owned by vfio-pci to make use of 3:00.0, but assigning them to the guest > is not recommended. Can you provided your qemu command line? I did hand all of them to the guest OS. Removing 1c.0 & 1c.6 from the qemu command line seems to have done the trick. Thanks! Here's my working qemu command line: qemu-kvm -no-reboot -enable-kvm -cpu host -smp 4 -m 6G \ -drive file=/home/test/qemu/images/win7_base_updated.qcow2,if=virtio,cache=none,media=disk,format=qcow2,index=0 \ -full-screen -no-quit -no-frame -display sdl -vnc :1 -k de -usbdevice tablet \ -vga std -global VGA.vgamem_mb=256 \ -netdev tap,id=guest0,ifname=tap0,script=no,downscript=no \ -net nic,netdev=guest0,model=virtio,macaddr=00:16:35:BE:EF:12 \ -rtc base=localtime \ -device vfio-pci,host=00:1b.0,id=audio \ -device vfio-pci,host=00:1a.0,id=ehci1 \ -device vfio-pci,host=00:1d.0,id=ehci2 \ -device vfio-pci,host=03:00.0,id=xhci1 \ -monitor tcp::5555,server,nowait > We need > to re-visit how to handle pcieport devices with vfio-pci, perhaps > white-listing it as a vfio "compatible" driver, but this still should > not interfere with devices external to the group. > > The DMAR fault address looks pretty bogus unless you happen to have > 100GB+ of ram in the system. Nope, definitely not. :) > vfio makes use of the IOMMU API for programming DMA translations, so an > reserved fields would have to be programmed by intel-iommu itself. We > could of course be passing some kind of bogus data that intel-iommu > isn't catching. If you're assigning the root ports to the guest, I'd > start with that, don't do it. Attach them to vfio, but don't give them > to the guest. Maybe that'll give us a hint. I also notice that your > USB 3 controller is dead: > > 03:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev ff) (prog-if ff) > !!! Unknown header type 7f > > We only see unknown header type 7f when the read from the device returns > -1. This might have something to do with the root port above it (1c.6) > being in state D3. Windows likes to put unused devices in D3, which > leads me to suspect you are giving it to the guest. There error does no longer occur. lspci now shows this: -- snip -- 03:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) (prog-if 30 [XHCI]) Subsystem: Intel Corporation Device 2008 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-