On 10.07.19 12:19, Ralf Ramsauer wrote: > Hi, > > on an Intel system, I'd like to assign a PCI Device (dual port serial > controller, 8250 compatible chipset) to a non-root cell. Please find > more details of the card in lspci-root.txt. This is the card as it is > seen by the root-cell, before being assigned to the non-root cell. > > As exemplarily shown for an E1000e card in linux-x86-demo.c, I followed > those steps to assign the card: > - Add memory regions > - Add the pci device > - Add its caps > - Add access bits to I/O ports > ... to the non-root cell configuration. > > In the non-root cell, probing of the card fails with: > [...] > [ 1.551079] serial 0000:01:00.0: enabling device (0400 -> 0403) > [ 1.559060] querying PCI -> IRQ mapping bus:1, slot:0, pin:0. > [ 1.574310] serial 0000:01:00.0: can't find IRQ for PCI INT A; > probably buggy MP table > [ 1.582375] serial 0000:01:00.0: Couldn't register serial port 20c0, > irq 0, type 0, error -28 > [...] > (see dmesg.non-root.txt) > > > AFAICT, while this card support MSI interrupts, the driver wants to use > legacy interrupts, but can't find the IRQ. In the non-root world, lspci > reports this would be 0, which is clearly not correct. > > In the root cell, the card has IRQ 16: > [ 1.921700] IOAPIC 0: > [...] > [ 1.921811] pin10, enabled , level, low , V(10), IRR(0), S(0), > remapped, I(000F), Z(0) > > The non-root cell knows this irqchip. Any suggestions what I'm missing?
No. nothing. This is in fact an unsupported case. The problem with PCI IRQ forwarding to other cells is that there are chipsets between the PCI slot and the IOAPIC, and they can affect the IRQ routing. Plus there is a high chance of interrupt sharing this way, something Jailhouse cannot resolve when doing device pass-through. Therefore, we do not address this case and only support MSI/MSI-X for assigned PCI devices on x86. > > I guess the kernel would like to access MADT tables, but we don't have > those tables of course. So how can the kernel detect which IRQ is being > used? Who or what carries this information (in case of legacy IRQs)? > > > > Not related, but this issue raised another question: On x86, we supress > probing of non-existent platform serial devices in non-root cells with > 8250.nr_uarts=n. Why do we have to do this? My local machine doesn't > have a single serial device, and the kernel doesn't even try to probe. > So why does non-root Linux? > > Is it again due to missing ACPI tables that carry such platform information? > Exactly. We do not have any other platform information that tells it that there are no platform UARTs to touch. > > Last but not least: The dual-port serial card has one interrupt, two I/O > regions and some MMIO regions (that I don't need). To assign the card, I > could also 'just' map the I/O ports and the interrupt to the non-root cell. > > Just out of curiosity: In this manner, would it be possible to share an > interrupt between two cells? If so, it should be even possible to > partition the card. See above: Interrupt sharing is only possible if there is a single trusted instance that terminates the common interrupt and then forwards it to the different drivers. Splitting this between guests means driving the UART from one or the hypervisor and emulating the other UART. Not our style. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/521c1b04-ab40-e566-5625-5827d3a7f2e2%40siemens.com. For more options, visit https://groups.google.com/d/optout.
