Maxim Levitsky <mlevitsk@xxxxxxxxxx> writes:
> On Tue, 2021-01-26 at 14:48 +0100, Vitaly Kuznetsov wrote:
>
>
> ...
>> _vcpu_mask(
>> static u64 kvm_hv_flush_tlb(struct kvm_vcpu *vcpu, u64 ingpa, u16 rep_cnt, bool ex)
>> {
>> struct kvm *kvm = vcpu->kvm;
>> - struct kvm_vcpu_hv *hv_vcpu = &vcpu->arch.hyperv;
>> + struct kvm_vcpu_hv *hv_vcpu = to_hv_vcpu(current_vcpu);
> You probably mean vcpu here instead of current_vcpu. Today I smoke tested the kvm/nested-svm branch,
> and had this fail on me while testing windows guests.
>
Yes!!!
We were using 'current_vcpu' instead of 'vcpu' here before but Sean
warned me about the danger of shadowing global 'current_vcpu' so I added
'KVM: x86: hyper-v: Stop shadowing global 'current_vcpu' variable' to
the series. Aparently, I missed this 'current_vcpu' while
rebasing. AFAIU, normally vcpu == current_vcpu when entering this
function so nothing blew up in my testing.
Thanks for the report! I'll be sending a patch to fix this shortly.
>
> Other than that HyperV seems to work and even survive nested migration (I had one
> windows reboot but I suspect windows update did it.)
> I'll leave my test overnight (now with updates disabled) to see if it
> is stable.
That's good to hear! Are you testing on Intel or AMD? With AMD there's a
stale bug somewhere which prevents Gen2 (UEFI) L2 guests from booting,
the firmare just hangs somewhere not making any progress. Both Hyper-V
2016 and 2019 seem to be affected. Gen1 guests (including Windows in
root partition) work fine. I tried approaching it a couple times but
with no luck so far. Not sure if this is CPU specific or something...
--
Vitaly
