On 7/10/19 7:22 PM, Jan Kiszka wrote: > On 10.07.19 18:28, Ralf Ramsauer wrote: >> >> On 7/10/19 6:13 PM, Jan Kiszka wrote: >>>> 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?
Latest kernel doesn't change anything. >>> >> >> I'm using the 4.19-rt jailhouse. Do you know of any relevant changes >> upstream? Anyway, it's worth a try, let me test upstream... >> >> At least for 4.19, it looks like I'm not able to easily switch to MSI. >> At the moment, I don't even understand why the kernel actually uses >> legacy interrupts, while MSI cap is present. Something is odd there, I'd >> expect that MSI is, if available, the perefered method. But even the >> root-cell after boot won't enable MSI. Still investigating... >> >> I hope that I can switch to MSI with maybe a dirty hack, but I need more >> time to dig through the kernel's PCI stack (PCI starts bugging me). You >> can find things there you never wanted to know! :-) > > I suspect you are using some 8250 derivative with a similar driver: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=172c33cb61da0df5ccbdf1a8e736c8837d165a00 > > Check your concrete driver for its interrupt allocation. Thanks for the pointer, this patch is really helpful and almost exactly what I'm looking for. I want to test the required changes of the driver on Linux without Jailhouse first, before I'm going to test it in a non-root cell. My device uses the standard 8250_pci driver. So I hooked in there, and tried the following hack: diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c index bbe5cba21522..55f8144ef3e0 100644 --- a/drivers/tty/serial/8250/8250_pci.c +++ b/drivers/tty/serial/8250/8250_pci.c @@ -3640,10 +3640,20 @@ pciserial_init_ports(struct pci_dev *dev, const struct pciserial_board *board) priv->dev = dev; priv->quirk = quirk; + pci_set_master(dev); + + rc = pci_alloc_irq_vectors(dev, 1, 1, PCI_IRQ_ALL_TYPES); + if (rc < 0) { + kfree(priv); + priv = ERR_PTR(rc); + goto err_deinit; + } + memset(&uart, 0, sizeof(uart)); uart.port.flags = UPF_SKIP_TEST | UPF_BOOT_AUTOCONF | UPF_SHARE_IRQ; uart.port.uartclk = board->base_baud * 16; - uart.port.irq = get_pci_irq(dev, board); + uart.port.irq = pci_irq_vector(dev, 0); uart.port.dev = &dev->dev; for (i = 0; i < nr_ports; i++) { Luckily, probing succeeds. For the device, lspci reports: 01:00.0 Serial controller: Device 1c00:3253 (rev 10) (prog-if 05 [16850]) [...] Capabilities: [68] MSI: Enable+ Count=1/32 Maskable+ 64bit+ Address: 00000000fee00438 Data: 0000 Masking: ffffffff Pending: 00000000 Doesn't look bad so far. MSI is enabled and in use. And as soon as I write to or read from the device (echo / cat), the MSI interrupt appears in /proc/interrupts. But cat won't receive anything, and echo won't write anything. In fact, echoing to the device stalls until I abort with ^C. In both cases, no interrupts occur (according to /proc/interrupts). That would have been too easy. 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/3bd05e0d-d888-ffef-96e7-ef7ce023f2f9%40oth-regensburg.de. For more options, visit https://groups.google.com/d/optout.
