On 10.07.19 15:58, Ralf Ramsauer wrote: > 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?
Yes, specifically platform UARTs. > > 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. Latest kernel already? > >> >>> >>> 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. Yes, I looked at devicetrees, but x86 does not evaluate them sufficiently, does not describe legacy resources this way (too much hard-coded probing remains), and it seems no one is working on improving that. Looked to me like a dead end, and I do not feel like we are in a position with Jailhouse (yet ;) ) to change that fundamentally. 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/99f6615e-3621-3a7a-7bea-33839e48653e%40siemens.com. For more options, visit https://groups.google.com/d/optout.
