On Mon, May 16, 2022, Maxim Levitsky wrote: > On Thu, 2022-05-12 at 21:27 +0000, Sean Christopherson wrote: > > On Thu, May 12, 2022, Paolo Bonzini wrote: > > > On 5/12/22 12:14, Maxim Levitsky wrote: > > > > Yes, this is the root cause of the TDP mmu leak I was doing debug of in the last week. > > > > Non working cmpxchg on which TDP mmu relies makes it install two differnt shadow pages > > > > under same spte. > > > > > > Awesome! And queued, thanks. > > > > If you haven't done so already, can you add > > > > Cc: stable@xxxxxxxxxxxxxxx > > When I posted my patch, I checked that the patch didn't reach mainline yet, > so I assumed that it won't be in -stable either yet, although it was CCed there. Yeah, it should hit stable trees because of the explicit stable@. The Fixes: on this patch is likely enough, but no harm in being paranoid. > > Also, given that we have concrete proof that not honoring atomic accesses can have > > dire consequences for the guest, what about adding a capability to turn the emul_write > > path into an emulation error? > > > > > This is a good idea. It might though break some guests - I did see that > warning few times, that is why I wasn't alert by the fact that it started > showing up more often. It mostly shows up in KUT, one of the tests deliberately triggers the scenario. But yeah, there's definitely potential for breakage. Not sure if a capability or debug oriented module param would be best. In theory, userspace could do a better job of emulating the atomic access than KVM, which makes me lean toward a capability, but practically speaking I doubt a userspace will ever do anything besides terminate the guest.
