On 08.12.20 10:46, Peng Fan wrote: >> Subject: Re: ARM64 MSIX enabling error >> >> 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 > > Indeed. > > - 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. > > This change make it work. I am using INTX, so num_vector is 1, however > if device vector is 2 or 1, it will ignore the interrupt inject in hypervisor/ > ivshmem.c > > @@ -361,9 +369,9 @@ int main(int argc, char *argv[]) > > memset(queue_config, 0, sizeof(queue_config)); > queue_config[0].size = 8; > - queue_config[0].device_vector = 1; > + queue_config[0].device_vector = 0; > queue_config[1].size = 8; > - queue_config[1].device_vector = 2; > + queue_config[1].device_vector = 0; > current_queue = -1; > > vc->config.cols = winsize.ws_col; >
OK, we need to explore how many vectors are available and configure the queues accordingly. I thought I did that already but apparently that wasn't for real. Or it was only for ivshmem-net... > > BTW: Do you think using kvmtool to include the virito ivshmemv2 > support is a good option? Or you insist standalone tool as your > current design? kvmtool is for... kvm. I'm not sure I you can easily factor out the device models from the kvm part there. I fact, I'm rather thinking of something list rustvmm to exploit as device model supplier on the long run. 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/5043bde5-fe69-398a-a0c6-9957459f2b57%40siemens.com.
