> Subject: Re: ARM64 MSIX enabling error > > 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...
Please help create a patch, I am a bit new to this. For ivshmem-net, do you plan to support virtio network? > > > > > 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. ok. I am not sure which is better currently. Rustvmm might be a good choice. Thanks, Peng. > > 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/DB6PR0402MB27604611BF7DE87E43799E3A88CC0%40DB6PR0402MB2760.eurprd04.prod.outlook.com.
