Hi, On 7/10/19 3:20 PM, Jan Kiszka wrote: > 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.
Damn. That's what I already feared… > > 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. Yep, in fact, this interrupt is shared with i801_smbus. > > Therefore, we do not address this case and only support MSI/MSI-X for assigned > PCI devices on x86. Logical consequence, I understand. Crap. For what reason do we then assign irqchips to non-root cells at all? Just for rerouting platform interrupts? Ok, there's one chance left: According to lspci, the device actually supports MSI. It's just not being used by Linux. Maybe I can somehow convince Linux to switch to MSI. > >> >> 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. Ok, so Linux's fallback seems to be to just register/probe everything. Hmm. This isn't a big issue at the moment (we can control Linux by cmdline parameters), but I always run into this pattern of issues/crashes when running non-root linux. Have you ever considered device trees for x86 non-root Linux inmates? Linux could also parse the commregion and only register and use the console that is listed there. > >> >> 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. True, just wanted to know if there would generally be limitations. Thanks for clarification! Argh, I hope the driver is able to switch over to MSI... Thanks Ralf > > Jan > -- 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/46aff85a-01ba-875e-1752-cb40f9080b31%40oth-regensburg.de. For more options, visit https://groups.google.com/d/optout.
