On 23.07.19 16:50, Ralf Ramsauer wrote: > Hi, > > I start a new thread, as this is now became another issue. Still working > on getting a RS232 PCIe card running in a non-root Linux cell. > > The good news: basically, it works. I can send and receive data via MSI > ints. > > serial 0000:17:00.0: enabling device (0400 -> 0403) > querying PCI -> IRQ mapping bus:23, slot:0, pin:0. > serial 0000:17:00.0: can't find IRQ for PCI INT A; probably buggy MP table > 0000:17:00.0: ttyS2 at I/O 0x4008 (irq = 24, base_baud = 115200) is a > ST16650V2 > > I still see the 'buggy MP' error, but it can be ignored as the driver > will eventually use MSI.
Yes. There is no MP table with Linux running as secondary Jailhouse guest. Thus, the driver can't get anything set up for its legacy INTx. > > > Two bad news: Linux's 8250 driver needs patching. At least we need some > parameter like 8250.platform=disable to disable the probing for platform > uarts. Why? > > ATM, we must specify 8250.nr_uarts. Otherwise the kernel will touch > restricted ports. It does touch those ports, as it lacks ACPI platform > information and assumes 'any' platform UART is present. Yes, nr_uarts is the patch-free approach for now. I once had a hack that propagated the information "this is Jailhouse, you may not find platform UARTs" to the driver. But that was a hack, so I didn't propose that upstream along with the other x86 changes. Plus, there are cases where we do want to use a platform uart in the non-root cell. > > I.e.: > 8250.nr_uarts=1 only touches 0x3f8 > 8250.nr_uarts=2 touches 0x3f8 and 0x2f8 > 8250.nr_uarts=3 touches 0x3f8, 0x2f8, 0x3e9 (?) > > In addition to that I have a PCI device. And Linux won't probe it until > it probed all other PIO ports. If I specify 8250.nr_uarts=1 (as I do > want to restrict access to 0x2f8), it will never probe the PCI device. > > So at the moment, the hack is to set 8250.nr_uarts=4 and permit access > to all ports. Yikes. At least I now know that the PCI device basically > works, but still, this needs to be patched. > OK, that was probably not yet addressed. We once had a setup with UARTs on a PCI card, but that machine also had no platform UARTs IIRC. If there no other way to tell Linux the number of platform UARTs, we will have to introduce one, for the sake of this use case already. > > Second thing: Sending/receiving works fine, but I still get VT-d fault > events. Such like: > > VT-d fault event reported by IOMMU 0: > Source Identifier (bus:dev.func): 17:00.0 > Fault Reason: 0x22 Fault Info: 8e000000000 Type 0 > > ... We don't have IR-PCI-MSI in non-root cells, right? So where does > this fault come from? We do not have guest-visible IR in non-root cells, right. We do have IR in place for them, though. And something is misconfigured here. It says that the device tried to send an interrupt although there was no programming for that in the IR table at index 0x8e. > > Note that before handing over the device to the non-root cell, the root > cell didn't load the driver for the device, so it should be handed over > unitialised. Check what the cell programs into the MSI capability of the device and how that propagates in Jailhouse. Sorry, once again this path :). 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/3d158812-b502-3641-f509-2508560aa51f%40siemens.com.
