On 09.12.20 02:35, Peng Fan wrote: >> 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.
Now I remember why there is no detection yet: UIO lacks proper support for multiple interrupt vectors. ivshmem-uio works around that by registering on all possible vectors and reporting them via the single event channel. But there is no interface for the UIO userspace part to find out how many vectors the device supports at all. We could either create such an interface - or we could enhance UIO directly to support multiple interrupt vectors. I'm leaning towards the latter... > For ivshmem-net, do you plan to support virtio network? > Not at this stage. It would require a better (more performant) virtio-ivshmem back-end architecture to handle network with similar throughput as we do via the symmetric ivshmem-net so far. >> >>> >>> 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. > I can't tell that for sure yet which path is best. I only had a look at the virtio backend implementations of ACRN for Linux, and those didn't appear worthwhile to reuse (too simplistic implementations, too bound to the restricted device model of ACRN). But from the perspective of current + growing popularity, rustvmm is likely the best candidate, after QEMU (which is likely harder to reuse). 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/3879a23f-0d6e-4aa0-f8bf-9774b4ddfff7%40siemens.com.
