Date:   Mon, 13 Feb 2023 17:38:23 +0000
From:   Sean Christopherson <seanjc@google.com>
To:     Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>
Cc:     Paolo Bonzini <pbonzini@redhat.com>, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org, Tianyu Lan <ltykernel@gmail.com>,
        "Michael Kelley (LINUX)" <mikelley@microsoft.com>
Subject: Re: "KVM: x86/mmu: Overhaul TDP MMU zapping and flushing" breaks SVM
 on Hyper-V
Message-ID: <Y+p1j7tYT+16MX6B@google.com>
References: <43980946-7bbf-dcef-7e40-af904c456250@linux.microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <43980946-7bbf-dcef-7e40-af904c456250@linux.microsoft.com>
Precedence: bulk

On Fri, Feb 10, 2023, Jeremi Piotrowski wrote:
> Hi Paolo/Sean,
> 
> We've noticed that changes introduced in "KVM: x86/mmu: Overhaul TDP MMU
> zapping and flushing" conflict with a nested Hyper-V enlightenment that is
> always enabled on AMD CPUs (HV_X64_NESTED_ENLIGHTENED_TLB). The scenario that
> is affected is L0 Hyper-V + L1 KVM on AMD,

Do you see issues with Intel and HV_X64_NESTED_GUEST_MAPPING_FLUSH?  IIUC, on the
KVM side, that setup is equivalent to HV_X64_NESTED_ENLIGHTENED_TLB.

> IIRC, KVM side always uses write-protected translation table to shadow and so
> doesn't meet such issue with the commit.

This is incorrect.  KVM write-protects guest PTEs that point at 2MiB and larger
pages, but 4KiB PTEs are allowed to become "unsync" and KVM's shadow NPT/EPT entries
are synchronized with the guest only on a relevant TLB.

I know of at least one non-KVM-hypervisor TDP TLB flushing bug that was found
specifically because of KVM's infinite software TLB.  That doesn't mean that this
isn't a KVM bug, I just want to call out that KVM-on-KVM should be capable of
detecting KVM-as-L1 TLB bugs, at least on Intel/VMX/EPT (KVM's nested SVM support
is woefully naive from a TLB flushing perspective and synchronizes guest PTEs
before every nested VM-Entry to L2).