Message-ID: <88a89319-a71e-fa90-0dbb-00cf8a549380@redhat.com>
Date:   Mon, 13 Feb 2023 13:50:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.1
Subject: Re: "KVM: x86/mmu: Overhaul TDP MMU zapping and flushing" breaks SVM
 on Hyper-V
Content-Language: en-US
To:     Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>,
        Sean Christopherson <seanjc@google.com>
Cc:     kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
        Tianyu Lan <ltykernel@gmail.com>,
        "Michael Kelley (LINUX)" <mikelley@microsoft.com>
References: <43980946-7bbf-dcef-7e40-af904c456250@linux.microsoft.com>
 <Y+aQyFJt9Tn2PJnC@google.com>
 <9a046de1-8085-3df4-94cd-39bb893c8c9a@linux.microsoft.com>
From:   Paolo Bonzini <pbonzini@redhat.com>
In-Reply-To: <9a046de1-8085-3df4-94cd-39bb893c8c9a@linux.microsoft.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 2/13/23 13:44, Jeremi Piotrowski wrote:
> Just built a kernel from that tree, and it displays the same behavior. The problem
> is not that the addresses are wrong, but that the flushes are issued at the wrong
> time now. At least for what "enlightened NPT TLB flush" requires.

It is not clear to me why HvCallFluyshGuestPhysicalAddressSpace or 
HvCallFlushGuestPhysicalAddressList would have stricter requirements 
than a "regular" TLB shootdown using INVEPT.

Can you clarify what you mean by wrong time, preferrably with some kind 
of sequence of events?

That is, something like

CPU 0	Modify EPT from ... to ...
CPU 0	call_rcu() to free page table
CPU 1	... which is invalid because ...
CPU 0	HvCallFlushGuestPhysicalAddressSpace

Paolo