On 08.12.20 09:01, Peng Fan wrote: > >> Subject: Re: ARM64 MSIX enabling error >> >> On 08.12.20 06:28, Peng Fan wrote: >>>> Subject: RE: ARM64 MSIX enabling error >>>> >>>>> Subject: Re: ARM64 MSIX enabling error >>>>> >>>>> On 07.12.20 08:46, Peng Fan wrote: >>>>>> Hi, >>>>>> >>>>>> I use MSIX, not INTX in root cell file, but always met the following >>>>>> error. >>>>>> uio_ivshmem: probe of 0001:00:00.0 failed with error -28 >>>>>> >>>>>> >>>>>> I am trying virtio ivshmem on my board, but seems virtio ivshmem >>>>>> vi_find_vqs not work with INTX, so I change to MSIX to see how. >>>>>> But met upper error, any suggestions? >>>>> >>>>> MSI-X for virtual devices only works when injecting them into a >>>>> physical PCI bus which is using MSI-X already. Is that the case here? >>>>> If not, you need to debug the INTx case. >>>> >>>> ok. Thanks. >>>> >>>> I could see virtio-ivshmem-console /dev/uio1 shows a few lines log, >>>> >>>> But it responds to input very slow, when I press enter key, it takes >>>> long time to respond. >>> >>> After correct the interrupt number, it responds to enter key fast. >>> But if I not press enter key, the virtio-ivshmem-console /dev/uio1 >>> will show nothing. If I press enter key, it will show one line boot log. >>> Press one more time, it will show the other boot log. >>> I need press enter always, then could see the boot log printed out. >>> >> >> Still interrupts issues, I would say. The GIC MMIO resources are not >> accidentally passed through? Does /proc/interrupts report events for the >> virtual device? > > ivshm_irq_handler is triggered in the beginning, for several times, but after > that, there is no interrupt triggered from inmate Linux to root Linux. > > The inmate Linux is dead loop in > __send_to_port > -> > 644 while (!virtqueue_get_buf(out_vq, &len) > 645 && !virtqueue_is_broken(out_vq)) > 646 cpu_relax(); > > If I press enter key in virtio-ivshmem-console /dev/uio1, it could pass the > loop. > But it will run into it again later and not break out. >
I bet the "virtqueue_kick" that comes before this loop does not trigger an interrupt on the backend side - or we have race that this is consumed without delivering the expected answer to the frontend. Didn't recall to see this, so I'm afraid you need to debug deeper. Jan -- Siemens AG, T RDA IOT 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/35de9824-dc88-dd3a-175f-6db6c086d2a6%40siemens.com.
