From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zachary Amsden Subject: Re: [PATCH] turn off writable page tables Date: Mon, 31 Jul 2006 15:40:19 -0700 Message-ID: <44CE86D3.8060108@vmware.com> References: <66edb0fb6e0664d309b10701168c495e@cl.cam.ac.uk> <44CA8369.9080200@vmware.com> <200607290105.46208.ak@suse.de> <44CA9974.9030804@vmware.com> <44CDCE1C.1000302@vmware.com> <07059add50c2b7826e967218da89c140@cl.cam.ac.uk> <44CE6055.3000902@vmware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: virtualization@lists.osdl.org, Andrew Theurer , xen-devel@lists.xensource.com, Andi Kleen List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > If the guest gives explicit hints, and the extra branch on set_pte > does not hurt, then I think it makes sense to do straightforward > explicit batching. Providing a PT page hint sounds like it could be > ambiguous in some contexts too (e.g., the fork loop modifies two PT > pages at a time). Yes, that is why I shyed away from passing PT hints - then you need to deal with the double hint case, and I think unhooking and revalidating two page tables probably does not make sense based on the UP writeable page table numbers. > >> The explicit batching does have one disadvantage without writable >> page tables, which is a potential long term maintenance / correctness >> issue - you must remove read hazards from these encapsulated paths. >> That is not so hard to do, and not a large general problem, because >> the batching is explicit rather than implicit, so you can pick paths >> to batch that are small, compact, and easy to reason about. But >> nevertheless, a point I would like to make sure you are comfortable >> with before we all decide these hooks will work for everyone. > > Yes, that's why we moved away from this approach before. But > previously we did it for *all* pagetable updates, which was a pain. > Doing it just for a few important cases, and having the hooks > maintained in upstream Linux, makes this rather less of a headache. Cool. It sounds like the lazy mode hooks are exactly what you want then? Cheers, Zach