On 10/15/2015 02:08 AM, Janusz wrote:
W dniu 14.10.2015 o 10:32, Xiao Guangrong pisze:
On 10/14/2015 04:24 PM, Xiao Guangrong wrote:
On 10/14/2015 03:37 PM, Janusz wrote:
I was able to run my virtual machine with this, but had very high cpu
usage when something happen in it like booting system. once, my virtual
machine hang and I couln't even get my mouse / keyboard back from qemu.
When I did vga passthrough, I didn't get any video output, and cpu
usage
was also high. Tried it on 4.3
Which tree are you using? Is it kvm tree?
Could you please work on queue brancn on current kvm tree based on
top commit 73917739334c6509: KVM: x86: fix SMI to halted VCPU.
Hmm... interesting, this diff works on my box...
Forgot to say that i built my test env following the instructions on
kvm-wiki:
http://www.linux-kvm.org/page/OVMF
My test script is attached, and i will try to build the env like yours
as much
as possible...
I cloned git://git.kernel.org/pub/scm/virt/kvm/kvm.git 73917739334c6509
commit, but this is breaking my system...
Slim is not able to start i3, xdm is not killing X when I stop xdm, qemu
is not able to start when I don't use option -nographic
log from qemu on that kernel version:
xcb_connection_has_error() returned true
No protocol specified
Could not initialize SDL(No available video device) - exiting
On main kernel branch I don't have those problems.
I tried to run with -nographic, and tried pc-i440fx-2.1 but the same
problem as before, high cpu usage and no graphic on my GPU.
I don't know if that will help by this is my log from option -global
isa-debugcon.iobase=0x402 -debugcon file:fedora.ovmf.log:
https://bpaste.net/show/36c54dba68c2
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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
