On 7/23/19 12:21 PM, Jan Kiszka wrote:
> On 23.07.19 12:16, Ralf Ramsauer wrote:
>>
>>
>> On 7/11/19 1:07 AM, Ralf Ramsauer wrote:
>>> 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.
>>
>> Turns out it is that easy. Code above works perfect, but the serial
>> card's MSI support seems to be broken. So I went for another PCIe serial
>> card, and now it works fine.
>>
>> Let me just advertise this product, in case someone else runs into the
>> same issue. [1] comes with two serial lines -- one PCI function per
>> line, which is pretty nice. Didn't try it yet, but it should be possible
>> to assign ports to different cells. Yet, the kernel needs to be patched
>> in order to enable MSI.
>
> Would that patch target this particular card? Or a chipset that is different
> from the one in the broken card? Then it might be worth pushing it upstream.
Yeah, I thought of this. Would definitely be valuable. I would have to
patch 8250_pci.c. It would require a whitelist, as it's not a good idea
to enable MSI for any card. There's at least one card where MSI won't
work. Hmm. I'll try to find some time for that...
Ralf
>
> Jan
>
>>
>> Ralf
>>
>> [1] https://www.amazon.de/gp/product/B0073LM0S4
>>
>>>
>>> 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/ce2fa8f3-1bc4-60ad-18fa-331fb87d5789%40oth-regensburg.de.
