On Thu May 03, 2018 at 11:18:03 +0800, nico.hacker wrote: > The previous test is not enough to cause error, this error is not related to > peripherals, I have removed almost all peripheral drivers<br /><br />In the > previous test, I added a delay operation before the vm2 start, so that vm1 > completely up and then start vm2, this will greatly reduce the probability of > the error. Now I removed this delay, vm1 and vm2 started simultaneously, then > the error will occur frequently (about 1/10 probability). The error is > generated when kernel processes vtimer interrupts. Under normal > circumstances, after processing a vtimer interrupt, the vcpu thread will > return to uvmm and then execute prepare_guest_entry(). This operation will > eventually enter the kernel through the system call to set the state of vcpu > thread, but when the error occurs, I find that the vcpu thread does not > execute vcpu_resume, it processes two consecutive vtimer interrupts. As a > result, the assertion fails.
Ok, I see. I've never experienced this, however I will try running VMs aggressivly concurrent and see what happens. > Is the kernel able to guarantee that the complete process of handling vgic > and vtimer interrupts (including the process in uvmm) is not interrupted by a > new interrupt? Yes, this is supposed to be the case. > Here's my configuration: You're aware that you seem to give both VMs access to the same UART device? (Will probably have nothing to do with the assertion.) Adam _______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
