On Mon, February 6, 2012 18:05, Ken Bass wrote: > Take a look at http://wiki.xensource.com/xenwiki/VTdHowTo > > Two things in particular about PCI passthrough: > > - Only devices with FLR capabilities are supported. > - Some motherboards are buggy. They advertised that they > support Vt-d > but do not correctly handle it (those with a broken ACPI > DMAR table) > > I think lspci -vv will tell you if the device supports > FLR. It will show > 'FLReset+' I believe. > 03:00.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart) (prog-if 06 [16950]) Subsystem: Oxford Semiconductor Ltd Device 0000 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 17 Region 0: I/O ports at d040 [size=32] Region 1: Memory at d0702000 (32-bit, non-prefetchable) [size=4K] Region 2: I/O ports at d020 [size=32] Region 3: Memory at d0701000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0+,D1-,D2+,D3hot+,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: serial No FLR string is present. So pci pass through is a dead end I take it? I increased the number of uarts available to the host system at boot with the 8250.nr_uarts=10 option. This gives me the following: # setserial -g /dev/ttyS* /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 /dev/ttyS1, UART: unknown, Port: 0x02f8, IRQ: 3 /dev/ttyS2, UART: unknown, Port: 0x03e8, IRQ: 4 /dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3 /dev/ttyS4, UART: 16950/954, Port: 0xd040, IRQ: 17 /dev/ttyS5, UART: 16950/954, Port: 0xd048, IRQ: 17 /dev/ttyS6, UART: 16950/954, Port: 0xd050, IRQ: 17 /dev/ttyS7, UART: 16950/954, Port: 0xd058, IRQ: 17 /dev/ttyS8, UART: unknown, Port: 0x0000, IRQ: 0 /dev/ttyS9, UART: unknown, Port: 0x0000, IRQ: 0 With this change I now can add one serial port (/dev/ttyS4) to a virtual guest using virt-manager and have the guest start, but no more than one. Any more that one and the guest fails to run with the same irq conflict error as before. I still have not tried to see if the serial port actually works in this case, just that the system starts. I ran across this thread relating to serial devices in qemu from some time ago: http://www.mail-archive.com/qemu-devel@nongnu.org/msg27354.html Which seems to me to imply that it is not possible for a qemu guest to have more than 2 serial ports, one of which I gather has to be the console. However, this statement attracted my attention: > This is wrong. Two devices should never be manipulating > the same qemu_irq object. If you want multiple devices > connected to the same IRQ then you need an explicit > multiplexer. e.g. arm_timer.c:sp804_set_irq. And in a later message in the same thread: > Two devices have the same s->irq. Give each on its own > qemu_irq, and feed it into a multiplexer that ORs them > together and sends the result to the interrupt > controller's qemu_irq: Is there a way to set irqs in quem to map to specific ports on a pci card as this seems to imply? How is it done? -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3