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?