> 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;
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?
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/DB6PR0402MB2760F7FE11280F9619178C5888CD0%40DB6PR0402MB2760.eurprd04.prod.outlook.com.
