From: David Gstir <david@sigma-star.at>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, richard@sigma-star.at
Subject: Re: DMAR faults from unrelated device when vfio is used
Date: Tue, 05 Feb 2013 14:31:50 +0100 [thread overview]
Message-ID: <1360071110.6200.19.camel@riven-lux.site> (raw)
In-Reply-To: <1359992968.11144.414.camel@bling.home>
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- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 18
Region 0: Memory at fe500000 (64-bit, non-prefetchable) [disabled] [size=8K]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D3 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [90] MSI-X: Enable- Count=8 Masked-
Vector table: BAR=0 offset=00001000
PBA: BAR=0 offset=00001080
Capabilities: [a0] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <4us, L1 unlimited
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
Capabilities: [140 v1] Device Serial Number ff-ff-ff-ff-ff-ff-ff-ff
Capabilities: [150 v1] Latency Tolerance Reporting
Max snoop latency: 0ns
Max no snoop latency: 0ns
Kernel driver in use: vfio-pci
-- snip --
Most likely because I don't hand the root ports over to the guest anymore.
However, there seems to be another issue with the USB 3 controller since
windows 7 can't start the device (error 10 in windows device manager). Using
these USB ports in the host linux worked fine. Could this issue be related to
pci-express?
Thanks,
David
next prev parent reply other threads:[~2013-02-05 13:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-04 10:10 DMAR faults from unrelated device when vfio is used David Gstir
2013-02-04 15:49 ` Alex Williamson
2013-02-05 13:31 ` David Gstir [this message]
2013-02-05 15:37 ` Alex Williamson
2013-02-05 20:36 ` Alex Williamson
2013-02-05 20:41 ` Richard Weinberger
2013-02-06 18:09 ` Richard Weinberger
2013-02-06 18:47 ` Alex Williamson
2013-02-06 20:25 ` Richard Weinberger
2013-02-06 22:45 ` Alex Williamson
2013-02-07 22:23 ` Richard Weinberger
2013-02-07 22:49 ` Alex Williamson
2013-02-07 23:26 ` Richard Weinberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1360071110.6200.19.camel@riven-lux.site \
--to=david@sigma-star.at \
--cc=alex.williamson@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=richard@sigma-star.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).