linux-kernel - Re: [PATCH 0/7] KVM: Alleviate mmu_lock hold time when we start dirty logging

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 20 Dec 2012 06:41:27 -0700
From:	Alex Williamson <alex.williamson@...hat.com>
To:	Gleb Natapov <gleb@...hat.com>
Cc:	Marcelo Tosatti <mtosatti@...hat.com>,
	Takuya Yoshikawa <yoshikawa_takuya_b1@....ntt.co.jp>,
	Takuya Yoshikawa <takuya.yoshikawa@...il.com>,
	kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/7] KVM: Alleviate mmu_lock hold time when we start
 dirty logging

On Thu, 2012-12-20 at 15:22 +0200, Gleb Natapov wrote:
> On Thu, Dec 20, 2012 at 10:59:46AM -0200, Marcelo Tosatti wrote:
> > On Thu, Dec 20, 2012 at 02:02:32PM +0900, Takuya Yoshikawa wrote:
> > > On Wed, 19 Dec 2012 08:42:57 -0700
> > > Alex Williamson <alex.williamson@...hat.com> wrote:
> > > 
> > > > Please let me know if you can identify one of these as the culprit.
> > > > They're all very simple, but there's always a chance I've missed a hard
> > > > coding of slot numbers somewhere.  Thanks,
> > > 
> > > I identified the one:
> > >   commit b7f69c555ca430129b6cde81e9f0927531420c5c
> > >   KVM: Minor memory slot optimization
> > > 
> > > IIUC, the problem was that you did not care about the generation of
> > > slots which was updated by update_memslots():
> > > 
> > >   Your patch reused the old memory slots which was there before
> > >   doing the update for invalidating the slot, and badly, we did flush
> > >   shadow pages after that before doing the second update for finally
> > >   installing the new slot.  As a result, the generation did not change
> > >   from that of the invalidated one, although the ghc(gfn to hva cache)
> > >   might be stale.
> > > 
> > >   After that, kvm_write_guest_cached() checked if ghc should be
> > >   initialized by comparing ghc's generation with that old one,
> > >   resulting mark_page_dirty_in_slot() was called with the invalid
> > >   cache contents.
> > > 
> > > Although we can do something to correct the generation alone, I do not
> > > think such a trick is worth it because this is not a hot path.  Let's
> > > just revert the patch.
> > 
> > Agreed. No dependencies by the following patches on it?
> Heh, this generation management looks subtle. Would be easy to break by
> other changes to the code. I wounder can we make it less subtle somehow.

Hmm, isn't the fix as simple as:

--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -847,7 +847,8 @@ int __kvm_set_memory_region(struct kvm *kvm,
                                GFP_KERNEL);
                if (!slots)
                        goto out_free;
-       }
+       } else
+               slots->generation = kvm->memslots->generation;
 
        /* map new memory slot into the iommu */
        if (npages) {

Or even just slots->generation++ since we're holding the lock across all
of this.

The original patch can be reverted, there are no following dependencies,
but the idea was that we're making the memslot array larger, so there
could be more pressure in allocating it, so let's not trivially do extra
frees and allocs.  Thanks,

Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/