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

[Janusz <januszmk6@gmail.com>]

W dniu 15.10.2015 o 09:10, Xiao Guangrong pisze:
>
>
> 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...
>
Yes, reverted MTRR code is already in kernel I use - 4.3-r5+