Hi,
On Thu Mar 29, 2018 at 20:48:34 +0800, nico wrote:
Hi l4 hackers,
I recently encountered an assertion failure error during the vm linux boot process, the kernel error is at src/kern/arm/thread-arm-hyp.cpp.
vcpu_vgic_upcall(unsigned virq) { ...... assert (state() & Thread_vcpu_user); ...... }
The thread reports this error while processing the vgic interrupt. I'm not sure where the thread state has been changed. The most suspicious is the function vcpu_enter_kernel_mode(), but the function is called in several places. I have updated to the latest version (l4re-snapshot-18.03) and the error still appears. There is also a phenomenon that if multiple VMs are started, the frequency of this error will increase a lot.
Interesting. Could you please be a little bit more verbose, e.g. what type of CPU/SoC you're using and whether you're on 32 or 64bit? Would I be able to reproduce this?
Adam
Hi Adam, I'm using an eight-core Cortex-A53 processor. The vm is running 64bit Linux. It is recommended to start two or three vms, that will be easier to reproduce this problem. Nico 在2018年03月30日 00:24,Adam Lackorzynski 写道: Hi, On Thu Mar 29, 2018 at 20:48:34 +0800, nico wrote: > Hi l4 hackers, > > I recently encountered an assertion failure error during the vm linux boot > process, the kernel error is at src/kern/arm/thread-arm-hyp.cpp. > ------------------------------------------------------ > vcpu_vgic_upcall(unsigned virq) > { > ...... > assert (state() & Thread_vcpu_user); > ...... > } > ------------------------------------------------------ > The thread reports this error while processing the vgic interrupt. I'm not sure > where the thread state has been changed. The most suspicious is the function > vcpu_enter_kernel_mode(), but the function is called in several places. I have > updated to the latest version (l4re-snapshot-18.03) and the error still > appears. > There is also a phenomenon that if multiple VMs are started, the frequency of > this error will increase a lot. Interesting. Could you please be a little bit more verbose, e.g. what type of CPU/SoC you're using and whether you're on 32 or 64bit? Would I be able to reproduce this? Adam _______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Hi Nico,
On Fri Mar 30, 2018 at 10:15:33 +0800, nico wrote:
Hi Adam, I'm using an eight-core Cortex-A53 processor. The vm is running 64bit Linux. It is recommended to start two or three vms, that will be easier to reproduce this problem.
So, I tried several things but cannot reproduce this issue. I assume this are single-core VMs only? Any hardware passed through? Just trying to narrow it down...
Adam
On Mon Apr 09, 2018 at 22:26:38 +0800, nico wrote:
Sorry, the last email did not specify this information. I gave VM1 all the hardware resources, and it used eight cores. VM2 only has uart resources (also timer, gic resources), using a single core. I tried to give both VM1 and VM2 only the necessary hardware resources( uart, timer, gic), and that error won't happen.
Ok, that's interesting. So that means that some of the passed through hardware is causing this. Would you be able to find out which device is causing this, by selectively enabling/disabling devices?
Adam
On 4/9/2018 06:28ï¼ Adam Lackorzynskiadam@os.inf.tu-dresden.de wroteï¼
Hi Nico, On Fri Mar 30, 2018 at 10:15:33 +0800, nico wrote: Hi Adam, I'm using an eight-core Cortex-A53 processor. The vm is running 64bit Linux. It is recommended to start two or three vms, that will be easier to reproduce this problem. So, I tried several things but cannot reproduce this issue. I assume this are single-core VMs only? Any hardware passed through? Just trying to narrow it down...
l4-hackers@os.inf.tu-dresden.de