On Tue, 2021-02-09 at 09:38 +0100, Vitaly Kuznetsov wrote:
> 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...
>
I never had luck with Gen2 guests on AMD (they did work on Intel last time I tried).
I have both Gen1 and Gen2 guests installed, and I boot them once in a while.
The VM I test HV with is running windows 10 pro build 1909.
On Intel both work, on AMD only Gen1 works. I can take a look, maybe I can spot something.
Do you know by a chance if WSL2 is a Gen2 guest? They have hidden it very well from the user
so you don't even know that you are running a VM.
About my 'windows update' theory, I was wrong, I just haven't given enough memory to
the HV host, and it eventually started getting out of memory crashes according to the event log,
so I upped the HV memory a bit and it survived ~900 iterations of nested migration so far.
Besides this,
I do have two HV bugs that I am tracking. One relates to not correct initalization of mmu
on nested state load, which is not HV specific but seems to be triggered by it VM
(I'll send a patch today)
Second issue, is if I run the HV host as a nested itself (which is overkill, but this can easily be not
related to this setup but just have different timings),
the HV host bluescreens eventually, after doing repeated migration of L1 guest
(L1 is linux with same patched kernel, L2 is HV host)
It does seem to work on Intel.
Best regards,
Maxim Levitsky
