[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1212437393.972.50.camel@bodhitayantram.eng.vmware.com>
Date: Mon, 02 Jun 2008 13:09:53 -0700
From: Zachary Amsden <zach@...are.com>
To: Jeremy Fitzhardinge <jeremy@...p.org>
Cc: Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
xen-devel <xen-devel@...ts.xensource.com>,
Thomas Gleixner <tglx@...utronix.de>,
Hugh Dickins <hugh@...itas.com>,
kvm-devel <kvm-devel@...ts.sourceforge.net>,
Virtualization Mailing List <virtualization@...ts.osdl.org>,
Rusty Russell <rusty@...tcorp.com.au>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 0 of 4] mm+paravirt+xen: add
pte read-modify-write abstraction
On Sat, 2008-05-31 at 01:13 +0100, Jeremy Fitzhardinge wrote:
> Zachary Amsden wrote:
> > We don't fault. We write directly to the primary page tables, and clear
> > the pte just like native. We just issue all mprotect updates in the
> > queue, and flush the queue when leaving lazy mmu mode. You can't wait
> > for the TLB flush, you must flush the updates before releasing the
> > pagetable lock, or you could get misordered updates in an SMP system.
> >
>
> How do you track which ptes need shadow updates? Do you walk the entire
> pagetable on tlb flush? Or just rebuild the shadow from scratch on demand?
No, we queue the updates as well as writing the primaries, we just flush
the queue before dropping the PT lock for one trip to the hypervisor.
--
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/
Powered by blists - more mailing lists