On 10/15/2015 02:58 PM, Janusz wrote:
W dniu 15.10.2015 o 08:41, Xiao Guangrong pisze:
On 10/15/2015 02:19 PM, Janusz wrote:
W dniu 15.10.2015 o 06:19, Xiao Guangrong pisze:
Well, the bug may be not in KVM. When this bug happened, i saw OVMF
only checked 1 CPU out, there is the log from OVMF's debug input:
Flushing GCD
Flushing GCD
Flushing GCD
Flushing GCD
Flushing GCD
Flushing GCD
Flushing GCD
Flushing GCD
Flushing GCD
Flushing GCDs
Detect CPU count: 1
So that the startup code has been freed however the APs are still
running,
i think that why we saw the vCPUs executed on unexpected address.
After digging into OVMF's code, i noticed that BSP CPU waits for APs
for a fixed timer period, however, KVM recent changes require zap all
mappings if CR0.CD is changed, that means the APs need more time to
startup.
After following changes to OVMF, the bug is completely gone on my side:
--- a/UefiCpuPkg/CpuDxe/ApStartup.c
+++ b/UefiCpuPkg/CpuDxe/ApStartup.c
@@ -454,7 +454,9 @@ StartApsStackless (
//
// Wait 100 milliseconds for APs to arrive at the ApEntryPoint
routine
//
- MicroSecondDelay (100 * 1000);
+ MicroSecondDelay (10 * 100 * 1000);
return EFI_SUCCESS;
}
Janusz, could you please check this instead? You can switch to your
previous kernel to do this test.
Ok, now first time when I started VM I was able to start system
successfully. When I turned it off and started it again, it restarted my
vm at system boot couple of times. Sometimes I also get very high cpu
usage for no reason. Also, I get less fps in GTA 5 than in kernel 4.1, I
get something like 30-55, but on 4.1 I get all the time 60 fps. This is
my new log: https://bpaste.net/show/61a122ad7fe5
Just confirm: the Qemu internal error did not appear any more, right?
Yes, when I reverted your first patch, switched to -vga std from -vga
none and didn't passthrough my GPU (case when I got this internal
error), vm started without problem. I even didn't get any VM restarts
like with passthrough
Wow, it seems we have fixed the QEMU internal error now. :)
Recurrently, Paolo has reverted some MTRR patches, was your test
based on these reverted patches?
The GPU passthrough issue may be related to vfio (not sure), Alex, do
you have any idea?
Laszlo, could you please check the root case is reasonable and fix it in
OVMF if it's right?
BTW, OVMF handles #UD with no trace - nothing is killed, and no call trace
in the debug input...
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
