Re: [edk2] KVM: MTRR: fix memory type handling if MTRR is completely disabled

[Xiao Guangrong <guangrong.xiao@linux.intel.com>]

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.