On 03/11/2015 15:35, Xiao Guangrong wrote: >>>>> >>>>> - if ((cr0 ^ old_cr0) & X86_CR0_CD) >>>>> + if (!kvm_check_has_quirk(vcpu->kvm, KVM_X86_QUIRK_CD_NW_CLEARED) && >>>>> + (cr0 ^ old_cr0) & X86_CR0_CD) >>>>> kvm_zap_gfn_range(vcpu->kvm, 0, ~0ULL); >>>>> >>>>> return 0; >>> (Honestly I just imitated fb279950ba here; I'm not making any better >>> argument for this diff. But, independently, I wonder why this hunk >>> didn't have the noncoherent DMA check either, originally.) >> >> Great job. I look forward to the testing results. >> >> It should also have the noncoherent DMA check, in fact, though that's >> just an optimization and it would have masked the bug on your system. > > Hmm... but kvm_zap_gfn_range even other shadow page zapping operations > are really usual behaviour in host - it depends on how we handle memory > overcommit/memory-layout-change on host. > > I doubt it is really a right way to go. kvm_zap_gfn_range() is just a time > delay factor to trigger OVMF boot issue but there must have other factors > have such delay too, for example, more vcpus in OVMF, high overload on > host, etc.
But it's pointless if the quirk is enabled. Also, bringing up APs will cause heavy contention on mmu_lock as Laszlo pointed out. Paolo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
